“云计算数据中心网络技术”有132个回复

1. XiaoQiang 于 2011-07-05 1:46 上午

   收了，要是分成章节的就好了：
   1，看起来可以轻松点；
   2，多骗首席点股份。

2. 匿名 于 2011-07-05 2:11 上午

   数据中心网络是最近网络研究热点，在学术研究方面，中国有一个研究团队走在世界前列。微软亚洲研究院网络与无线组，领军人物是张永光和郭传雄，无论是做学术的还是工程的，都建议去了解一下他们的成果。http://research.Microsoft.com/wn

3. 陶业先 于 2011-07-05 2:34 上午

   Nice paper.有图版更赞。

4. 苹果橙 于 2011-07-05 3:18 上午

   不错！超赞！

5. 土人 于 2011-07-05 5:36 上午

   估计弯曲中的巨著啦

6. EX8200 于 2011-07-05 7:31 上午

   这个要巨顶一下，信息量丰富！

7. slopover 于 2011-07-05 7:34 上午

   信息量好大，慢慢看

8. IP+Optical 于 2011-07-05 7:44 上午

   Great Article

9. 陈怀临 于 2011-07-05 7:51 上午

   谢谢Roy贤弟。功德无量呀。。。是，写这样的文章比写代码难多了。。。

10. wenfish 于 2011-07-05 7:56 上午

    好长啊

11. Roy 于 2011-07-05 8:15 上午

    多谢大家捧场，小弟是个懒人，分章节和贴图工作量太大，整了个含图的word版放在最前面供大家下载来慢慢看。。。欢迎指正与讨论。

12. kblue 于 2011-07-05 8:22 上午

    很牛的文章，多谢多谢

13. oioi 于 2011-07-05 8:45 上午

    巨作，好好学习，还是弯曲上的牛人多

14. russellw 于 2011-07-05 8:50 上午

    信息量很大，感谢作者的贡献，草草浏览一番，几点看法：
    1、虚拟化在通信、计算机领域的本意是分区和隔离，在一个大的资源池里面划出一块来让使用者感觉如同独占使用一般，Centrex、VPN、VLAN、Server Virtualization均是如此；计算领域的多虚一属于分布式系统的概念，网络领域也是集中管控、资源捆绑的概念，套用虚拟化概念是少数厂商借人气的做法，有点像云计算兴起后，所有的C/S，B/S架构全部变成云计算了。
    2、OTV已经在IETF有草案了，目前个人草案是01版。
    3、LISP用在多站点互联中Cisco给出的解决方案是和OTV结合，LISP负责管理MAC到站点的映射关系、虚拟机移动后Client访问的路径优化，OTV负责MAC地址的学习，向LISP更新VM IP/MAC和站点的绑定关系。另外，PITR我理解应该部署在靠近用户的骨干节点附近或eBGP Router附近，采用任播方式发布Datacenter的IP前缀，以导引流量就近接入

15. bigrong 于 2011-07-05 9:16 上午

    先顶一下，好文章。我喜欢的领域和我喜欢的口味！

16. zj 于 2011-07-05 9:47 上午

    好长的文章

17. CCC 于 2011-07-05 11:00 上午

    文章还未深度，挑点小刺
    64是报文最小载荷，20是IP头长－－20不是IP长，IP已经在64里包含了。20指8字节前导码和12字节最小以太帧间隙

18. CCC 于 2011-07-05 11:48 上午

    初读了一下，是篇深入浅出的好文章，虽然部分推断可能有误，但毕竟很多厂商都不会将细节公开，另外火箭放得太凶，也影响了判断。非常感谢作者的辛劳，有大家风范！

19. huaboy 于 2011-07-05 3:11 下午

    非常感谢作者的辛劳，有大家风范！

20. 知迷不悟 于 2011-07-05 5:20 下午

    俺土，文档压缩包应该是什么工具看啊？

21. 理客 于 2011-07-05 5:27 下午

    赞无言

22. steveawei 于 2011-07-05 5:43 下午

    先膜拜一下，再下载学习

23. Sting 于 2011-07-05 6:18 下午

    功莫大焉

    尤其欣赏文章中思路清晰，观点明确的文风，不可多得啊

24. 房地产商 于 2011-07-05 6:29 下午

    写的很好，已拜读，弯曲又一个强著，作者真才实学，既懂又能讲清楚，难能可贵，希望能继续！

25. 郁秀 于 2011-07-05 6:54 下午

    如果当真如文中所说的——云计算是多虚一，那和网格计算又有什么本质区别呢？

26. 郁秀 于 2011-07-05 6:58 下午

    上面的问题是我一直以来的困惑，望哪位高人给解释一下

27. Panabit 于 2011-07-05 6:59 下午

    高人！

28. slo 于 2011-07-05 7:00 下午

    写的非常不错，长见识了

29. 陈怀临 于 2011-07-05 7:10 下午

    >并纪念作者步入而立之年

    30岁？简直可怕。如果是共军部队，共军确实人才鸡鸡呀。。。

    30岁能写出这么深的文章。。。我今天去高铁卧轨了。

    对N7000的评审，基本上与我对CRS－1的文章有一拼了。

    贤弟，太谢谢你了。

30. tom 于 2011-07-05 7:31 下午

    不顶不行，不赞不行

31. gaohl 于 2011-07-05 7:51 下午

    受益，关注后续安全方向的文章，顶。顶顶。。顶顶顶。

32. kernelchina 于 2011-07-05 8:45 下午

    能转成pdf会更好一点，不是每个人都能安装word，支持一下

33. francis 于 2011-07-05 8:52 下午

    高人啊，茅塞顿开。

34. 某某 于 2011-07-05 9:46 下午

    应 kernelchina 的要求，我转了一个 PDF，发到首席的 email 邮箱了，有空的时候首席好发一下。

35. longw 于 2011-07-06 12:11 上午

    不多说了
    眼泪哗哗的
    感动的
    难道一见的巨作

36. caqlm 于 2011-07-06 12:44 上午

    上班的时候看的，还没看完，回家接着看
    写的真好

37. 哈哈 于 2011-07-06 1:40 上午

    难得一见的好文章啊，作者能留个邮箱吗？

38. tony 于 2011-07-06 2:32 上午

    有理有据，有时间好好学习下

39. AC 于 2011-07-06 3:08 上午

    再讲个故事—–这部分看得非常不爽。你的确说的不对，讲故事的那个人92年就开始做网络方面的研发工作。你所列的没有考虑的事当然是考虑过的。DC网络结构针对弹性计算和并行计算也不能一概而论，将建设成本考虑进去答案自然出来。

40. nauticar 于 2011-07-06 3:14 上午

    难得的好文章，连我这个门外汉都看懂了。强大

41. Leo 于 2011-07-06 4:40 上午

    写的非常好，推荐给了很多朋友。作者刚30，就写出这样的文章，佩服啊！

42. Leo 于 2011-07-06 4:40 上午

    写的非常好，推荐给了很多朋友。作者刚30，就写出这样的文章，佩服啊！

43. ZCS 于 2011-07-06 5:02 上午

    猜想作者也数通设备厂商工作。作者对CISCO、H3C、Junier产品和技术都分析的很清楚。

44. Roy 于 2011-07-06 6:02 上午

    感谢大家的关注，希望能够给每个看到的人都有一些帮助。
    to russellw
    1、虚拟化个人觉得一虚多属于隔离和分区的目的，而多虚一则有所不同。
    2、我4月份最后接触OTV的消息时，还是说在专利评审，没想到这么快就上Draft了，看来Cisco也是等不起了，赶快先给技术正个名，名正则言顺，更好忽悠。
    3、LISP+OTV的资料也看过一些，但感觉对文中描述的LISP那两个问题也没有很好的解决，至少是没有把这块儿技术处理流程说明白。

    To CCC
    多谢指正，确实是错误。一会儿就改过来。

    To 郁秀
    云计算目前从概念上用云服务更准确一些。文中意思是指其中集中云的计算多虚一是从网格计算发展而来，还有分散云的一虚多技术这一大块。
    本质区别由于我对网格计算这块儿并不是十分清楚，所以不敢乱说，还请熟悉的兄弟帮忙解惑。

    To 哈哈
    k_xw@sina.com
    欢迎技术讨论，但工作原因访问频率会比较低，如回复较晚请见谅。：）

    To AC
    个人观点：
    1、数据中心这种电老虎就应该建得离城市越远越好，建在雪山峡谷是非常Nice的Idea，从成本和能耗各方面考虑俺都举双手赞同。
    2、目前国内由于私人不能拉光纤，更别提维护了，这种通信资源都处于几大运营商垄断的市场状况下，还不具备将大型数据中心建立到偏远地区的条件。
    3、只有以后类似铱星这种无线通信技术成熟后，可以甩开运营商解决网络通信问题，雪山峡谷的Idea才能真正落实。
    4、这个事正是因为我只了解个大概，所以跟大家就当作故事来讲一下，绝对没有任何褒贬的意思在里面，如果有误会纯粹是我的文法不过关所致，致以真挚的歉意。

45. 网络达人 于 2011-07-06 7:21 上午

    云数据中心网络方面的Bible!

46. ToddHan 于 2011-07-06 10:15 上午

    1、在无阻塞以太网技术也可以为iSCSI服务，TCP卸载成熟后iSCSI应该也有作为的，同时由于IP可以跨越三层网络，应该也不比FCoE的前景差才对的，

47. 土人 于 2011-07-06 2:45 下午

    to 知迷不悟
    该成docx 文件名

48. ronnie 于 2011-07-06 7:06 下午

    现在从事私有云产品研发工作。就我的了解，中国的SAAS服务是最多的，很多的中间件厂商都进入的这个领域。 比如用友， 八百客， 维库等等。 但这种模式的SAAS 服务目前在中国， 前景堪忧。因为它并没有开创新的软件， 只是换了个软件使用方式。而且使用门槛高，复杂。 用户需求不那么迫切。
    PAAS 中国有几家， 小的不说了， 大的有SAE（sina app engineer）， 可能阿里也有计划。
    IAAS，恰恰中国是最少的， 公有的IAAS服务， 必须是大公司才能让人放心。 目前盛大， 阿里貌似在开发， 还不成熟。

    在云的基础技术解决方案上，国内做的好的是华为，另外还有一些个小公司， 但我看他们产品， 都是copy 开源来的， 商业化还很远。

49. ronnie 于 2011-07-06 7:15 下午

    我倒认为CLOS 是未来高端分布式交付机/路由器的方向。
    他解决的问题，不仅仅是架构性阻塞问题， 而且为分布式系统的提供了足够的灵活性。
    比如用三级CLOS架构， 可以为不同容量的单板提供线速保证。 如果第一级的CLOS芯片能力为100G，200G的单板，该单板可以用2个， 如果另外一个单板需要400G， 可以用4个芯片。 同时， 二级芯片网板相应增加， 这就为产品未来扩展提供了可能。
    另外， 他提供的交换的冗余与可靠性也是高端设备非常看重的。 他的VOQ 技术在流媒体， QoS 上，都起着非常重要的作用。

50. ronnie 于 2011-07-06 7:25 下午

    作者蛮倾向与cisco的，猜的， 作者是cisco的？

    我现在从事数据中心云的工作， 为了解决虚拟化带来的问题， 也研究了下TRILL， VEAP等这些新技术。 我现在在想， 数据中心里， 需要这么复杂的技术吗 ？
    首先，数据中心的网络需求， 相对运营商网络来说，其实简单的多，加上虚拟化后， 大二层网络 + 多路径技术 + VM接入识别， 一个DC， 涉及到的也就上百台网络设备。 那么，如果把这些流量都集中管理， 集中的策略来处理他的负载，多路径， 应该也能做到。
    比如， 集中的， 智能的网管，EMS 系统。
    or， openFlow？

    openflow 现在还不成熟， 但基于现在的商业芯片， 在上面开发一个集中的管理平面，复杂流量规划，负载均衡，冗余和故障检测，应该能成吧？

    另外， 现在有没有网管平台，能够实现全网的，基于现在交换机mib 的管理，配置能力呢？ 这个在一个数据中心里， 开发难吗》

51. ronnie 于 2011-07-06 7:30 下午

    集中的管理平面， 不管是openflow， 还是 智能网管， 都是硬件厂商们不愿面对的， 但这恰巧是新公司的机会，而且就数据中心的需求来说， 应该也不难。

    有人做这个吗？

52. ronnie 于 2011-07-06 7:34 下午

    对ISCSI， 以前， 一般来说， 大数据读取， 对性能影响很大。
    而现在， 有这样的HBA， 可以独立完成ISCSI的工作， 但service系统可以提高的100M/s， 与分布式文件系统性能较为接近。 应该来说， 基本能满足一般性需求。

53. ronnie 于 2011-07-06 7:41 下午

    回25楼，
    我的理解， 多虚一与网格计算， 都是技术层面的事情， 技术本质上， 他们都是分布式计算。 没有什么差别。

    但网格技术与云又是不同的。
    网格计算强调的是技术， 而云， 更强调的是IT，软件的交付和使用方式的变革。 他背后的技术， 可以是网格计算， 比如Google， 也可以是虚拟化技术， 比如Amazon， 也可以是多租户技术， 比如是salesfalse。 这些都只是云的技术实现。

54. 狐说 于 2011-07-06 8:05 下午

    卫星通信有可能达到那么大的带宽吗？

55. ronnie 于 2011-07-06 8:09 下午

    数据中心互联， 还的是光纤。 呵呵

56. nonono 于 2011-07-06 9:55 下午

    Roy今天在公司内部就红透半边天了，人才啊！还有，外界的朋友不要动不动崇拜思科，笑而不语！

57. ronnie 于 2011-07-07 2:37 上午

    下午在拜读了下lz 大作， 还有个问题：LISP有多少用户选择？ 感觉设计太复杂了。
    跨地域数据中心的LB， 为什么不能放到内网来处理呢？ 一般来说， 内网状态同步信息在一般公司都以有实现了。

58. Roy 于 2011-07-07 6:49 上午

    To ToddHan
    iSCSI目前总的市场趋势还是在增长，但非常缓慢。Server-Storage之间的网络必须是高速、低延迟和无丢包的，而IP转发恰恰不擅长上述三个要求。因而个人觉得，IP SAN市场空间一定会有，但一定会落后于FCoE和FC。

    To ronnie
    感觉老兄更多的关注于云平台方面，文章里也说了，目前云计算中很多厂商的切入点都是云平台，既通过一套完整的管理系统完成资源管理调配和业务交付。
    这个平台跟网络、服务器和存储等硬件相关的其实就是能够根据用户定义自动下发配置即可。
    MIB是很通用的手段，但一般都只能管理公有协议，各厂商的私有协议MIB就不是那么容易获取的了。
    开源的统一管理平台很多，各个IT厂商也都很容易切入。
    对Clos架构来说，如果希望在交换机内实现多级交换网，其实还有一个问题需要解决。空间。目前实现了一级Clos的这些交换机（125）和路由器（CRS）哪个不是超级大块头。如果再多放一级交换网板进去，真成巨无霸了。
    LISP目前只是个试验性技术，看到Cisco在北美搭建了一张试验网，没有听说商用实例。而且就技术而言，个人认为其如果想在数据中心应用，就必须对一些细节再处理清楚，目前的技术内容还不具备可实施性。对你问题中的内网不是很清楚指什么网，多站点选路的网络技术是应用于Client边缘设备到数据中心站点边缘设备之间。选路指Client选择去往Server的道路，这个问题仅仅依靠数据中心内部设备目前还没有看到有解决方案出现。

    To 狐说
    一切皆有可能，将今天的不可能变为明天的现实，也正是我们这些技术人员的价值所在。

59. nexus 于 2011-07-07 7:44 上午

    Roy, 你对6500的性能描述有问题，Sup720时，即使67xx板卡没有配置DFC，数据通道还是可以通过你所谓的FIRE来经过switch fabric，因此性能并不是你讲的32G。关于目前的技术，一个板卡上可以放置几个FE? 4个是太保守的了，不用等1～2年，很快你就可以看到令你惊讶的结构。CLOS用在交换机上？调度算法目前看有Egree credit, self routing, 那个都不如central arbitration，只不过multicast有点头痛。另外，个人看好 Openflow， Trill/FabricPath/QF/SPB 神马都是浮云。

60. 理客 于 2011-07-07 7:59 上午

    目前转发，无论L2还是L3，都是硬件转发，时延都小于us，一直说L2转发快于L3，有具体测试数据吗？
    对于DC，要求什么样的时延？
    实际的DC，是否都是在GE/10GE线速流量下运行，还是不会超过链路带宽的90%？

61. AC 于 2011-07-07 9:41 上午

    latency 和 packet loss是3Q的关系。无法回答DC要求什么样的时延，原因在于与业务相关。在线交易就是时延敏感类，一笔交易前端与后端之间的请求来回二三十次是普遍情况。所以单向*30是多少可想而知。而离线计算则是丢包敏感类业务，最常见的问题是TCP incast. 因此on-line与off-line是否同时run在一台x86服务器上也就带出网络结构及设备选型的trade-off.

    实际的DC中带宽利用率小于90%。所以line-rate永远是厂家之间的斗争与OTT无关。

62. AC 于 2011-07-07 10:17 上午

    我有几个问题：
    一、10K服务器的数据中心是指同一个网络集群是10K+还只是一个数据中心有10K+服务器，这是两个截然不同的情况，麻烦可否透露下。再有可否简单介绍下网络结构？
    二、S-S 之间你认为二层最好，可否解释理由？3000台hadoop集群用二层组网？
    三、Inter-DC之间跨二层的主要驱动来自于vMotion, 可否了解过到底有多少做弹性计算业务的公司非要跨数据中心的无缝迁移？如果有具体cast study可以分享将非常感激.

63. 理客 于 2011-07-07 2:12 下午

    to AC:那最敏感的业务对时延要求是多少？L2/L3转发引擎本身带来的时延都是微妙级，那为什么还说L3路由交换时延和抖动大？
    链路负载不超过90%，对于都是用线速非收敛的物理接口情况下，应该说无论L2/L3，都不会有丢包问题。

64. ronnie 于 2011-07-07 5:24 下午

    Clos 是有空间的问题， 所以一般都放在高端设备上， 比如HW 5000E ， H3P 的12500等。现在的Clos 一级芯片集成了调度模块， 这样，线卡上NP or TM 的空间就可以节省出来了。

65. ronnie 于 2011-07-07 5:27 下午

    我的观点跟Nexus类似， 数据中心不需要那么复杂的技术， openflow 在数据中心足够了。 现在的商业交换芯片足够应付数据中心需求，上面要做的就是个职能管理平面，国内腾讯就有这个计划。 也许， openflow 最先就在DC里可以落地。

66. ronnie 于 2011-07-07 5:47 下午

    我确实是在从事云IT平台工作。然后在平台上再做个APP交付。 类似与Apple Stone 。呵呵。

    而对你说的私有mib 问题， 我的前提是数据中心需求简单， 设计到的无非就是端口mib， vlan mib等一些公共mib。 so， 职能网管也能应付。 现在的问题是， 所谓职能-即能自我收敛与调整的网管， 我还没见过。 （可能我是孤陋寡闻了， 还请知情人士提点下）

    另外， 对IP-SAN， 我觉得可以在HBA卡上做文章， 封装， 加速， buffer处理等应该能大大降低丢包率，至于高速，本身就取决与自身网络， 该不是大问题， 现在BCM等做了个这样的HBA卡， 有兴趣可以研究下。

    IP-SAN 的未来取决于产业链上的公司支持， 他可以满足低成本业务的需求。 当然，要赶上FC 和 FCoE 还有段距离。

    to AC， 我所知道的， google 的一个集群可以到10K台。三级CLOS架构。一般一个集群3000到5000台就可以了。
    跨数据中心迁移， 需求应该很少，一般跨数据中心做数据备份就可以了吧？ 跨数据中心的大二层，本身安全性， DC与DC的带宽都是问题， 为什么要做这么大一个呢？ 目前我没看到客户有这样的需求。

67. AC 于 2011-07-07 6:24 下午

    To ronnie
    1 DC规模问题是想了解作者所知道的国内的现状。国内一个单网络集群10+我真是很想了解了。
    2 支持openflow的思路
    3 Iner-DC 的大二层我也认为是投入产出比很不划算的事，因此也具想了解到底有什么样主今天就这么搞了。LISP还没出生，SNAT方案哪里支撑得住业务要求。

    To理客
    1. 我已举了例子，latency不是网络工程师眼里一个end-end的过程而是一个trancation的来来回回几十次才会完成，因此放大系数放大了latency对在线交易的影响。
    2. 丢包的问题建议你读下”Understanding TCP incast throughput collapse in datacenter networks”这篇文章。
    在mapreduce环境中，网络工程师需要跳出box和转发层面来看应用带来的流量流向的变化。

68. anonymous 于 2011-07-07 6:36 下午

    已经看了一半，先向作者表示感谢。

69. 根本不相干 于 2011-07-07 11:00 下午

    很给力的文章，非常感谢。学习了！

    不过，楼上Ronnie的观点“跨数据中心的大二层，为什么要做这么大一个呢？目前我没看到客户有这样的需求”，我也有同感，这里提出来想请大家讨论一下（这个问题还涉及到文章中相当大部分的篇幅）。

    问题：二层网络的范围及其流量模型究竟是怎样的？

    即使象Google超100K节点的大型DC里也是以4-5K(10k估计也有，但应该是极端情况)左右为单位切成cell/cluster，cell内是低收敛比的高速连接，满足文章中所说的TOR-Core两级网络结构，而且GFS/BT/MR等分布式算法资源池主要在cell内进行cell之间主要做相互容灾和负荷分担，内聚性并不强。

    对非google这类一虚多的场景，情况更简单，因为没有哪个租户有这么大的资源需求，从资源池能力角度看，完全没必要跨集群。那么就只剩一个需求：灾备。现在的问题是，对有容灾需求的客户，其容灾协议又要保持二层，而且是高速实时同步，又能接受IAAS部署模式的客户的实际流量需求，到底有多大？诚然，银行之类要搞自己的远程数据实时灾备，但那绝对是光线/波分直连，而且这种系统根本不可能放在云里，换句话说，这类应用系统不是云计算的目标客户。

    所以我的判断是，一个务实的运营商应该只会把二层网限制在cluster/cell内（或者以前忘了谁提出的网络模块的概念，都类似），cell之间还得走三层，不管是DC内还是DC间。cell内带宽和交互时延需求相对苛刻，cell间则要求不严格。对于小部分比例确实需要cell间需要模拟出“二层连接”的，可以用各种类GRE技术模拟（比如Cisco OTV，以及开源open vswitch的GRE隧道）。银行把两台SAN磁阵从北京到上海连起来玩灾备，那玩意确实不是目前IAAS能伺候的，还是专网合适。

    假如这个判断成立（二层网限于一个有限的两级组网结构），那我们回过头来看一下，Trill/SPB之类物理拓扑上的大二层技术，是否真的比CLOS/QFabric之类简化方案有优势？我个人是有些怀疑的。

70. 理客 于 2011-07-07 11:30 下午

    to AC，感谢回复，可否理解为无论L2/L3转发，其us级的转发引擎带来的时延在整个业务时延里，可以忽略，因为业务层面transaction的设计和处理带来的时延才是问题的关键？
    另外，目前核心超级交换机，一台就可以支持1600个GE，如果4台cluster就是6400GE，此时，所有服务器间是一跳可达，这种交换机是否适合DC网络建设？

71. AC 于 2011-07-08 12:29 上午

    理客：
    1. 我的point是：
    a. cut through和deeper buffer 是case by case的选择，权衡和妥协。web、app、DB 需求各不相同，绕口地讲每设备单向转发延时可以忽略，但端到端一个交易完成所用的时延会扩大转发时延，所以此延时又不能忽略。
    b.app的优化的空间还很大，网络仍是管道，我现阶段认为KISS原则仍为第一原则。
    2. super-switch理论上适合，我们曾经也有此想法和计划。要考虑的因素有：1.成本。2.布线。3.非自建机房每机架的电所带来的每机架服务器的数量。4. 可靠性。挂掉一台就是1K台服务器没了。

72. 需要TOR 于 2011-07-08 1:22 上午

    to 理克:

    从实际工程角度，每个机架上还是要有一个1U的小盒子，把服务器网口的出线汇聚一下再往上送，否则太乱了。而且，4台core switch如果直连服务器，那每个服务器不是要出4根线，那样很难实施啊

    to AC：

    尽管端到端一个交易完成会扩大转发时延，但此时主机侧软件协议栈处理的时延会被放得更大，因此网络时延仍微不足道。举个例子，网络时延1us，主机软件绕一下是10us，那10个来回后，网络时延被放大到10us，但此时主机软件时延则已经是100us，仍然占大头。

73. Lucifer 于 2011-07-08 1:38 上午

    挺长的，支持一下，不过长了就难免错误，随便写一个吧：

    SR-IOV中的SingleRoot……Root是指PCI Express总线当中的RootComplex，根复合体，掌管着PCI Express与CPU等部件的交流，中断、DMA等的运作都需要经过RootComplex。每个RootComplex下挂了一堆PCI Express设备组成的树

    通常一台机只有一个PCIe RootComplex，因此MR-IOV提供了用PCIe总线将多台物理机器连接起来的方法（中间要通过PCIe交换机）。在这种环境中，某一设备可供不同机器上的不同虚拟机使用。

    另外，SR/MR-IOV的作用是提供一种VM和设备直接通信的方法，以降低延迟提升性能，它并没有提供VM直连的作用（MR-IOV也没有提供一个通用的物理机直连的界面，虽然实际上是连接了起来），这方面，需要通过Intel VMDq这样的技术来完成。VMDq或类似的技术就是有点接近一个硬件交换机了，由于VMDq在Intel网卡中几乎是标配了，82574、82575、82576这样的芯片都带有，因此应用也应该很广了

74. AC 于 2011-07-08 3:08 上午

    48口xG fixed L3 switch一定要提锐捷，两块LION背对背。细节就不帮人家做广告了，不过这款交换机性价比值得推荐。

75. 理客 于 2011-07-08 4:38 上午

    to AC，所以我理解L3转发引擎带来的比L2多的小于1us的转发时延，相对于整个网络中转发路径的时延，是可以忽略不计的，所以用时延抖动来否定L3应该是不存在的。
    单台设备成本肯定是非常高，但如果考虑opex，应该至少不会比现在一堆交换机高很多。
    布线问题，对现存机房是个较大问题，对新建机房，工程上肯定有办法，之前老韩测试过一款高密布线产品，很强。
    可靠性都是和麻烦事，在server和核心交换机之间直接做MC-TRUNK，我不知道现在的server是不是一般都支持eth trunk

76. 陈怀临 于 2011-07-08 6:36 上午

    “Roy今天在公司内部就红透半边天了，人才啊！还有，外界的朋友不要动不动崇拜思科，笑而不语！”

    哪个部队的？感觉是共军？但不知道是第几野战军的。。。广州军区深圳军分区的？还是北京军区的，成都军区的？杭州军分区的？

77. AC 于 2011-07-08 8:31 上午

    双挂服务器端是没有任何问题的，NIC配成mode=4就好了。但交换机为支持inter-chassis的802.3ad(CISCO的VPC）成本必提高。云计算几个assampution 之一就 硬件是不可靠的，所以data要跨机架跨交换机的存三份，但就算是goolge也应该承受不了一下没了1000台服务器的情况，但为了可靠搞得投资很大显然也不对。

78. Roy 于 2011-07-08 8:48 上午

    再次对大家的厚爱表示谢意。
    基于一些原因，必须要删除此源发帖内容。如果给大家带来任何困惑和不便，在此致以深深的歉意。

    to nexus
    65的架构部分没有问题，可参考Cisco network2010中ARC里面的介绍65的文档。S32和S720的PFC都只有一个BUS双向32G的接口外联，因此当接口板没有DFC时，整机转发瓶颈在于主控PFC的BUS通道。看一眼结构图就清楚了，可惜这里不方便贴图。：）
    板卡上的FE如果你指转发芯片或者是交换接口芯片，目前我看到最多的是Arista75上48*10GE接口板有6个双向160GE的转发芯片（肯定也需要6个交换接口芯片配合）。如果指交换芯片，目前不论是主控上还是交换网板上最多一块板子就2个，没有见过更多的。后续发展个人认为芯片能力提升会优于布局方面提升，但二者肯定都会有所发展的，谁先谁后而已。
    至于Clos在交换机上的发展，在文中已经用吃米饭进行了举例，个人觉得够用就好，没有什么是一定的。

    to Lucifer
    谨受教，谢。

    to others
    1、通过管理平面控制数据转发的模式个人不是很看好，网络规模有限的情况下能搞定，规模大了就不好说了，可靠性和维护都会有问题。个人理解OperFlow应该类似于PBB-TE的概念，有市场，但持疑。
    2、l3转发比较l2转发如果都是交换机处理的话，延迟不是大问题，关键是组网复杂度和可维护性。引入IP层势必要引入相关的路由寻址协议，OSPF/ISIS等技术目前对数据中心而言都无法支持内部几百个网络节点的大规模组网，CPU处理协议报文就干不了其他事情了，如果再出现个震荡啥的，基本全部歇菜，这点哪个设备厂商都搞不定。
    3、目前的二层网络规模说实话没有多大的，因为毕竟TRILL等二层技术并不成熟，没有相关条件去搭建这么大的运营网络。但由于大三层组网有2中所述规模限制，因此大二层在以后的数据中心个人认为是必然结果。至于到时候应用规模到底会有多大，还要看具体应用，如搜索引擎以后达到几k规模的二层组网真不是什么难事。10k的是某国字号企业，指服务器总数。
    4、只要X86能够始终引领潮流，TOR的结构就始终会压倒EOR，千兆接入万兆核心个人认为还得有个3-5年的市场，因此现在和短时间的将来衡量核心交换机要看其能支持多少个10GE接口转发能力，而非GE。

    to 陈首席
    多谢关爱，给您添麻烦了。：）

79. 理客 于 2011-07-08 8:51 上午

    是核心switch的一个线卡可靠性高，还是一个小box可靠性高？
    inter-chassis trunk，我不知道是否需要硬件芯片支持，还是软件处理即可。
    成本比较，DC的opex比capex更重要

80. ronnie 于 2011-07-08 8:56 上午

    从上网时间来看， 确实像共军的。但介绍技术又过于倾向Cisco 了。 所以， 又有点像集成商的:)

81. AC 于 2011-07-08 10:04 上午

    opex和capex对我们而言同样重要，capex比例网络占整个DC的7%~10%。越过肯定会想其它方案。说别人家的事，在别人家的机房（绝对头牌的那家）看到服务器双网口，分别接到两张网，两张网的本质区别在于网络收敛比不同。那么eth0和eth1里分别在跑什么发挥想象去吧。嘿嘿。

    我指的可靠性是指TOR这层，48口TOR挂一台，丢48台服务器，如果是3000台服务器的集群48服务器丢得起，如果96个口也丢得起，再高密度的TOR是否可行呢，所以TOR的密度越高分母也要增大才靠谱。

    ROY分析的二三层组网不准确，如果有机会欢迎到互联网公司交流下便于你理解。已有在线6000个口三层到边noblocking DC网。二层咋搞，广播咋控制？因此在最前面的建议便提出如果要论“云DC的网络架构”弹性计算和并行计算可能要用两个分支分别看。

    TO：需要TOR
    完全一致的观点，所以说是case by case的看latency，而不能在选型时一列latecy打分，一列line rate打分。

82. ronnie 于 2011-07-08 10:19 上午

    AC 说的， 我猜是管理网和数据网分开， 管理网简单，可靠性/带宽要求低，收敛比高无所谓， 甚至可以是100M网卡。

    可靠性即使从整个网络路径来说， 用两层结构也比一级super-switch好， 一个边缘AS down 掉， 影响有限。 而一个core down ，在一般网络模块设计里， 都还有2到3个core负载均衡互联。 这样至少不影响业务可用性。
    super-switch 的一层架构， super-switch 间的流量要有多大？？core 之间怎么互联？

83. AC 于 2011-07-08 10:40 上午

    管理有带外口啊。我特指生产网。

84. 理客 于 2011-07-08 11:42 上午

    1、支持近千台路由器在一个IGP domain的电信网络早就商用了
    2、在DC，通过一个chassis支持至少几百个GE的情况下，即使不用支持过千GE的chassis和cluster，一个也DC用不了多少台L3 SWITCH
    3、目前ISIS/OSPF fast convergence已经很成熟，简单组网可以达到毫秒级的收敛
    4、MAC天生的不安全不可靠不好管理不好维护，出了问题，比如广播风暴，难定位

85. 理客 于 2011-07-08 1:58 下午

    cabling可能确实是过千GE chassis的一个关键问题，也许单纤双向还不够，具体方案可以是布线超强的机柜（老韩之前介绍过一家最强的布线产品公司），再就是分离式布线设计，用专门的外置接线盘，还有就是用WDM GPON拉远，总之布线还是可以找到方案的。这里面，是可以有一些搞头的
    但一个chassis接的server数量，如果处于可靠性考虑，也许应该限制在几百台，这个要看工程实践经验，server和两个chassis做trunk，未必就不能解决可靠性问题。

86. ronnie 于 2011-07-08 5:48 下午

    to AC， 还真不清楚这两口干嘛的， 呵呵。
    不过， 再猜下， 就是一个内网口，内部Service间数据交互， 一个外网口， 收敛比高。

    我自己有个一个设计， 一个网口做业务出口， 一个做分布式文件系统内连口（非SAN）。 与上面的猜想貌似有点类似， 哈哈。

87. 陈怀临 于 2011-07-08 6:00 下午

    没看懂Roy的意思，要把文章卸下？？我来查一下email。

88. gaohl 于 2011-07-08 6:51 下午

    不解，不知道是何方压力：）理解

89. nexus 于 2011-07-08 8:09 下午

    Roy, 6500在67xx板卡上没有配置 DFC时，只是将数据包的前64字节送给PFC进行L2/L3查找，数据的交换还是通过交换芯片来进行的，你可以说对没有DFC的67xx板卡的pps能力是30mpps, 但是它的数据带宽是20/40gbps每个方向。

    你的米饭比喻忘记一点，虽然你只能吃两碗米饭，但是Clos/Benes这套烧饭的家伙事儿有点贵，芯片大都采用cell based，fabric ingress/egress需要SAR/Re-Assamble, scheduling 又复杂，S2/S3的加速比还要考虑，我认为在20Tbps的平台（两碗饭)时，Clos/Benes价格不好。

90. sun 于 2011-07-09 3:40 上午

    为何没有了呢。

91. ykzj 于 2011-07-09 8:24 上午

    我了个去

    没看到内容

    只看到块碑

92. 理客 于 2011-07-09 3:12 下午

    拜读大作，受益匪浅，楼主确是DC网络高手，敏而好学，亦善学，文章深度广度兼具，大部分观点，深表赞同，也略抛一点砖头在：
    1、vMotion处理VM移动的业务中断时，可能可以借鉴LTE中X2接口的处理方法：在路由没能及时更新导致仍然流向原VM的流量，原VM再通过X2接口转给新VM
    2、DC内部设备应该用私有IP，所以IP地址不应该是阻止L3 DC的问题。
    3、以太天生冲突问题CSMA/CD是HUB时代的事，从千兆开始，已经彻底没有这个问题了
    4、J不做交换机芯片不是技术问题，J的自研ASIC是其能在IP CORE立家之本，不做交换机芯片，是市场问题，不是技术问题
    5、RPR基本没有前途，到1OGE就基本结束生命了，原因有些和ATM类似：太复杂导致难以跟上以太的高速列车，太贵族也和以太平民风格不符，可以作为历史悼念一下了，基本上不可能有PBB咸鱼翻身的可能。PBB在2009年被运营商网络拍死，除了技术上确有不足，更多的原因在于ZZ，它触动了思科的一大片奶酪，但没有思科的支持，目前IP网络，哪个大的变革能过得了关？就如美国老大在ZZ中一样，没有美国点头，ZZ世界的协议就基本是废纸
    6、以太环路保护的public标准是G.8031
    7、网卡接入及交换机，真的会用到netflow等这么高级的特性吗？但最后交换芯片入server的结论正确
    8、私有协议确有标准落后和不可规避的客户实际需求原因，但确实是以私心为主。
    9、TCP的QOS为什么不能替代FC的QOS？
    看了楼主的全面分析，可以看到，如此复杂的诸多麻烦，可以说主要是L2引起的，一直没有解开到底全L3的DC有什么不行？但DC历史上选择了L2，就如当初的国军一样，可能就是不归路了，再改L3，估计是内外具反。
    技术说到底只是一个工具，尤其是在中国，甚至是辅助工具，如果不是真的对技术情有独钟，还是把它当作通往其他职业道路的一个工具。
    楼主可能在思科的一个重要的partner，文章对思科交换机产品分析很深刻，可能引用了一些不允许直接公开的资料，尤其是对65的分析，命中思科要害，除了这些能引起boss的麻烦，没有找到文章中其他可能引起麻烦的地方。

93. 赞成L3 于 2011-07-09 11:03 下午

    大L2不会存在于任一互联网公司（多虚一）场景里，Hadoop、GFS啥的不会没事找事，给自己整一个带来大麻烦的网络限制

    只有一虚多，而且多半是私有云，L2才可能会有需要。公有云不会有哪个运营商没事迁移来迁移去，折腾。真有的话，L2 over L3仿一下当二等公民算了，效率低点，但不会把底层物理网络搞得乱七八糟。只要现实中这种类型的流量不是主流，对整体效率就不会有影响

94. 姜中正 于 2011-07-10 6:00 上午

    首席，你有这个文件吗?有的话给我发一个。jiangzhongzheng112@gmail.com。谢谢了。

95. 年轮 于 2011-07-10 8:17 上午

    看完了之后，过来好好顶一下，写的实在太好了。

96. 陈怀临 于 2011-07-10 3:32 下午

    在另外，一个文章里，是整理的PDF文件呀。你可以download 之。

97. AC 于 2011-07-10 10:57 下午

    To: Roy
    想了几天仍想不清楚你讲ACE+GSLB的基于SNAT 的vmtion的方案是如何实现的，具体问题如下：
    1、两个物理DC对外通告路由的策略如何完成？
    2、两个物理DC之间下面那团云是传统接入SP的方案还是传输直达？L2 over L3?
    3、vCenter与GSLB联动对vm的地址的调度如何实现的？200台host machine , 每个host 20台VM。比如X.X.X.X/ 20的网段在左边，其中扣出几个不连续的地址迁移到了右边。

98. 麦克 于 2011-07-11 2:28 上午

    1、一直没明白为什么数据中心一定要l2组网，如果把isis这些协议移植到l2，那么和层三又有多大差别呢？而移植后，一定还会遇到层三遇到的全部问题。原来osi7层协议中，层二定位为数据链路，如果要组网，肯定会涉及到网络层的协议。现在通过改造层二协议在层二实现路由，反而把事情越高越复杂。

    2 用层二组网，cisco的vss 或者h3c的css，在一段时间内也完全满足要求，等这个方式搞不定了，通过 clos类似技术直接进行 做成超级交换机不是更简单。跨广域网机房的组网需求，目前应该还不明显吧。

    3 我理解l2组网的一个驱动力似乎是 迁移后ip地址不变的需求。不过这个需求应该并不是最终需求，最终需求是 迁移后对业务没有影响。不知道理解是否正确。

    3 用三层组网的话，网络层是比较成熟的，也可以做到快速收敛，计算到存储这块，还可以继续使用二层协议。主要问题可能在于部署起来比较复杂。对维护人员的要求就比较高。

    4、总体的感觉是trill类似的协议方案太复杂，给用户暴露了不必要的复杂性。根本需求是一个超级大的交换机，有成百上千个端口，至于内部实现其实不需要暴露给用户。 另外l2跨广域网的需求可能是个伪需求，真有远程备份的需求，可以通过其他方式实现。

99. 麦克 于 2011-07-11 2:45 上午

    to AC
    2. super-switch理论上适合，我们曾经也有此想法和计划。要考虑的因素有：1.成本。2.布线。3.非自建机房每机架的电所带来的每机架服务器的数量。4. 可靠性。挂掉一台就是1K台服务器没了。

    成本的化，应该主要是核心交换的成本，线路板的成本都是一样的。这个要依赖与商业公司的技术成熟度了。
    布线的话，把超级交换机设计成远端模块和核心交换，远端和核心之间使用内部接口，光钎直连，布线一定比交换机直接连接要简单。
    可靠性：既然是超级交换机，核心交换一定是双平面设计，如果还不够，可以作为1+1 互备。

100. AC 于 2011-07-11 4:13 上午

     布线是指垂直布线，1000个GE的交换机机架布线咋搞？
     a. 搞rackable switch,将服务器当成刀片一样一条一条插到背板上，然后40G或100G互联。
     b. N2K和N5K那种关系也可以，模块上行还是单点啊。双挂就是跨机箱的技术问题了。

     可靠性的问题，再双sup，四电源都会有OS bug吧，谁了伤不起挂一台网络设备挂1000台服务器的状况。

     换个思路，光纤入服务器可以等xG，从现在SSD的出货量，万兆接入可以跟搞出1000GE的super-switch时间点差不多了吧。xG接入，incast的问题又可以延时几年。

     不过真见过的某个PP的roadmap for DC as a switch。qfabric没研究过，不知道在4000台集群规模下的每端口成本。期待牛人写篇文章学习下。

     –以上纯是胡说8道。

101. Roy 于 2011-07-11 9:01 上午

     To AC
     站点A和站点B之间二层互通，vMotion前后IP地址不变，假设其IP为10.100，两个站点的VRRP/HSRP不互通，各自均有网关10.1。站点A的ACE做SLB后对应NAT后的虚IP为1.1，站点B对应虚IP为2.1。vMotion前GSS解析地址均为站点A的1.1，请求到达ACE后做DNAT变化目的IP为10.100，vMotion后vCenter通知GSS将新的请求解析为2.1，经站点B的ACE做DNAT后，同样变化目的IP为10.100，新建连接随之切换到访问站点B的RealServer上。

     To others
     如文中所言，路由和交换是网络中永恒的主题，个人理解数据中心内部网络中，性能和可靠性是最重要的，这两个方面L2都要比L3具有更大优势，后续会在相关外篇中详述个人理解。
     此处简单说两句，首先L3组网规模有限，上百个节点对路由拓扑计算压力就已经很大。但在将网关降到接入层时，几百个网络节点规模的数据中心将会很常见。
     其次L3的故障处理和拓扑收敛速度较慢，不过这也是我对TRILL/SPB等引入L2 ISIS协议后的疑虑。
     然后是表项处理，大MAC表可以做到支持几百上千k的内容处理，而且相对便宜，但IP表项就要差远了，路由表、FIB和ARP一个都不能少，对设备来说全部大范围提升相当有难度。不光是容量的问题，表项大了之后查表效率也必须相应提升，否则延迟增大同样受不了。
     还有些其他方面的考虑，等通过文档整理清楚了会再和大家分享。

102. 理客 于 2011-07-11 9:36 上午

     1、性能：L3 SWITCH基本和L2 SWITCH一样
     2、可靠性：ALU的新ME用EOMPLS为什么已经被业界广泛认可？其中重要原因之一是L2天生不可靠，FC诞生之时不用普通L2，是正确的选择
     3、L3 switch下，通过大型L3 switch，可以有效减少几倍的路由节点
     4、近千台路由器在一个IGP domain早就商用
     5、ISIS/OSPF的快速收敛远高于STP，最快达到毫秒级
     6、硬件实现的转发引擎包括各种表项查询，所带来的时延是微妙级，在业务转发的毫秒级时延中，几乎可以忽略
     7、对于L3 SWITCH，就是通用的以太L3交换芯片，其capex成本的增加，如果真的算起来，比目前要实现的复杂的L2各种协议，可能还要小
     8、数据中心的路由数量，10K的server，能有多少路由？即使真的有海量路由，目前并不用TCAM做，而是廉价得多的查表器，可支持上百万路由。

103. AC 于 2011-07-11 10:06 上午

     To Roy：再次讨扰，你指的站点A和站点B是指DC-A和DC-B吗？两个不在相同物理位置的DC不用VPLS、不用OTV、不用LISP如何能二层通？我还是想不明白

     ===========此处简单说两句，首先L3组网规模有限，上百个节点对路由拓扑计算压力就已经很大。但在将网关降到接入层时，几百个网络节点规模的数据中心将会很常见。=====
     1. L3组网规模毫无争议的比二层要大，否则全球大二层的intenet了。
     2. 一个服务器集群100多个L3交换机OSPF的fat-tree组网已相当常见，我指是已在线生产而且运行时间越过1年了。
     3. 互联网路由又不会直接灌到TOR这一层，8K LPM常见规格完全够用
     3. 反而大二层请注意在三层网关的ARP 反而是问题，这在学术界有不少paper，你可以找来读读。

104. 根本不相干 于 2011-07-11 6:55 下午

     to Roy：
     从物理组网角度，L3无疑是全面胜过L2的（除了90年代初那种几十个节点的工作组网络），这点我相信大家应该不会有分歧吧？

     而DC里之所以还要探讨L2，是因为“一虚多”环境下引入的虚拟层要保持“IP地址与VM位置”无关。“多虚一”为什么不会有问题？因为所有运营商都是基于应用层做了LBS，从根本上绕过了对IP地址的苛求（实际上他们的应用根本没有迁移的问题，server宕了也不管，业务数据重新生成新的mirror）。而“一虚多”中的IAAS由于要照顾Legacy应用，只好把L2提上日程。

105. 根本不相干 于 2011-07-11 7:00 下午

     即使在IAAS环境中，真的需要大L2的场景又有多少呢？vMotion是常被引用的证据，可是大范围跨集群资源池的迁移并不是一个常规的管理任务，更像一个纯粹的技术演示。对于少部分一定需要运行在广播L2网上的业务，而且还需要VM分布在大范围跨集群里互联，仿真一下虚拟的L2对运营商是一个负担更小的选择，而不是相反去吧物理网络折腾成大二层

106. medcl 于 2011-07-11 7:05 下午

     哪去了啊？

107. AC 于 2011-07-11 7:21 下午

     F105, 击掌！
     运营了一年多的IaaA，只见到三次的迁移，一直没有搞清是什么驱动将vmtion 提得这么高调，同时弹性计算的支撑网络用二层是可以理解，可是说它能做得规模很大完全不认同，一个host虚20~30台正常吧，2000台server，60KMAC，晕菜了吧，Trill也是有局限性的。但并行计算的hadoop 集群的网络是可以搞得很大的，三层到边，10K+的单一网络是没问题的，incast也是有解的，问题来自于hadoop集群本身还不到５０００台的物理服务器。

108. 根本不相干 于 2011-07-11 7:48 下午

     incast也是两种思路：增加switch buffer，或者减小server里tcp stack的RTO值。国内有互联网运营商提出huge buffer需求，google等估计是自己优化TCP stack了

     Anyway，这无关L2/L3，即使是10K+的hadoop也一样。事实上，单一hadoop集群，和二层网是两个无关的话题。1）hadoop不需要持久IP，也没有迁移之类的概念，任何节点都可以宕掉，系统不会假设宕掉的节点还会回来。2）hadoop是单播IP通信，没有利用任何网络组播/广播特性，关键的一致性是通过paxos分布式选举算法搞定。据我所知，还没有哪个搭建好的hadoop集群是依靠了以太网的二层特性的。

109. ronnie 于 2011-07-12 1:18 上午

     to AC&根本不相干， 我的观点类似， 大二层应对的就是虚拟机IP地址持久化的问题。 与应用本身，跟hadoop无关。 跨DC的迁移更多的是技术的渲染， 要真部署，性价比太低。

110. Roy 于 2011-07-12 7:10 上午

     to nexus
     6500交换机没有DFC的CEF720接口板+Supervisor720主控的转发性能确实如你所说，应该是只有报头部分走32G的BUS去主控的PFC绕一圈做处理，数据会被缓存在FIRE中。整机性能不止32G。这两天天查了一堆资料终于弄明白此处，十分感谢勘误。
     to AC
     A/B就是指两个站点，这里的多站点选路技术的前提条件就是假设多个站点间已经解决了二层通路问题，至于使用VPLS/OTV都可以，我们先认为两个站点的物理服务器之间二层可达，再继续设计GSLB的相关内容。
     to others
     云计算数据中心使用L2还是L3组网估计会是后面几年内的重点探究内容，目前阶段确实已经有几个100+ OSPF节点的FAT tree项目已经运行了一段时间，正因为接触过这些项目，了解到其中有一些问题是目前的L3技术所解决不好的，因此才认为L2多路径技术是解决大型数据中心多节点互联的根本之路，L3的FAT TREE只是在TRILL完善前的权宜之计。
     当然这个只是我的一家猜测之言，后面会发展成什么样子大家可以边讨论边拭目以待。

111. 理客 于 2011-07-12 8:07 上午

     “其中有一些问题是目前的L3技术所解决不好的”
     能否略作详述？

112. CLOUD 于 2011-07-12 9:27 上午

     看了一大部分，无论广度和深度都俱佳。对于L3希望能补充详细阐述下。有几个疑问：
     1、L3性能问题，控制平面多核协议分布式后性能不是瓶颈。

     2 VM IP寻址问题，用移动IP、ANY CAST技术改进。

     3 L2 TRILL和FCOE两者结合有场景吗，两次封装不可行啊。

113. Ucloud 于 2011-07-14 12:31 上午

     请教一下，公有云、一虚多的方式里。对不同用户的互访、隔离有什么好的建议嘛？同一用户里面有不同的网段交叉。

114. 宋伟 于 2011-07-20 8:32 上午

     我觉这个论文里面对硬件的网络虚拟化介绍的比较详细，其实还有很多软件的方案。 比如vswitch

115. CLOUDer 于 2011-07-29 8:30 上午

     来晚了，只见空碑及评论若干。 弯曲是要时时上的，教训.

116. 陈怀临 于 2011-07-29 11:40 上午

     http://www.tektalk.org/?p=16162 PDF version

117. CLOUDed 于 2011-07-29 3:40 下午

     多谢Joy和首席！云计算网络这块，因为利益不同，Cisco和微软各走不同的技术路线,几年内也会争的一塌糊涂…

118. CF 于 2011-07-30 11:58 下午

     L3在多虚一的access-core环境里, 对core switch的igp neighbor 可扩展性的要求比较高，一台core动不动就得支持上百个ospf neighbor。即使在internet环境下一台core router 有上百个igp peer也会出现这样那样的问题 （这也就是最近几年multi-chassis core上的多了才出现的问题），何况DC switch，各厂商本身对 switch L3的scalability和 convergence 就没投入太多精力。

     L3当然好，但vendor心中有各自的算盘。。。

119. CF 于 2011-07-31 12:02 上午

     补充一下：
     在ISP网络里 一个IGP跑上千个node一点也没问题。。。一个box要支持上百个IGP peer就会有点问题。

     跑BGP peer是另外一回事。

120. 李小辉 于 2011-09-03 10:05 下午

     roy 你好。能告诉我你的邮箱吗？我有事找你。
     我的邮箱是：lxh_h@sina.com

121. freemanhjr 于 2011-09-19 7:24 下午

     Roy,你好，我想请问采用VEB技术的话，从virtual switch到交换机的包带的MAC是VM的MAC还是网卡的MAC。
     能把你的邮件告诉我吗？有很多问题想请教

122. luzhenning 于 2011-11-01 7:40 上午

     粗粗的读了一编，符合深入浅出的风格。也研究过一些数据中心网络的东西，楼主的资料算是比较新的了，但是很多资料还是有很多的局限性，因为每个厂家都在很短时间内更新了资料。比如思科的N7K,主要定位在数据中心，出了2代交换矩阵，导致每槽位的能力大大提高。还有就是65，思科不会主动放弃，2T引擎以后还是主打企业市场（定位不同）。
     还有就是48口万兆，force10也有对应产品，H3C也是。还有思科N3K，大家都通用芯片，差不多的。
     以前数据中心市场不大，最近也是各个大厂家忽悠起来的，带动交换机的发展，具体业务在国内还是没跟上。（或者说没有达到云计算的规模。）

123. 出来混的 于 2012-02-09 9:11 下午

     我想看看，为什么看不到？难道有权限？

124. Cham 于 2012-03-17 9:07 下午

     我看了一下文章的全面部分，信息量充足，通俗易懂。

     多谢Roy的work.

     我有个疑问，文中提到虚拟化的三个技术分类OS-level, hosted, and bare-metal. 貌似文中更趋向于说OS-level的效果更好。bare-metal方案在os-level和hosted方案之间。但是我觉得bare-metal虽然实现上不如os-level简单，不过一旦实现了，它的性能应该高于os-level和hosted方案。

     roy，求指教，^_^

125. 狐说 于 2012-07-10 12:30 上午

     y=x*1000/2/8/(64+20)，1000是G到M的转换，2是双向，8是每字节8比特，64是报文最小载 荷，20是IP头长
     更正一下，20是IFG+preamble

126. 瀚云 于 2012-07-17 7:19 下午

     来这里的就不要反复的培训基础了好吧？大家不是来看入门教程的~~如果连帧间隙和前导字节都不知道的话自己百度一下算了~再说这个东西真要说清楚你还得从头讲，也不是一两句话就能说清的，比如为啥64是最小帧长？为啥IFG是12字节？为啥有llc/snap/ethernetII这几种封装?……

127. 狐说 于 2012-07-20 2:02 上午

     ls的何出此言，我以为搞技术的本来就是应该就事论事，培训基础谈不上，像ls这样懂的人自己略过即可，不了解的人若是死抠IP头为何要算进去，岂不是白费脑细胞？再说了，写的人还没整明白呢，谁说一定就没必要呢？

128. wonderful 于 2012-07-20 6:50 下午

     来晚了，还没有看到就删除了，可惜

129. wonderful 于 2012-07-20 6:51 下午

     谁下载发我一份，多谢了。2990719@qq.com

130. 糊涂 于 2012-07-22 8:22 下午

     @wonderful: 你要是耐心看完每个评论就知道如何找到原文了。

131. wonderful 于 2012-07-29 3:59 上午

     116 楼有，多谢 @糊涂

132. xiwen8383 于 2012-08-21 1:02 上午

     roy的文章我重复看了5次，在这第5次，通过前期做思科数据中心项目和不断看数据中心相关的网络技术后，才算真正看懂了roy大师的大部分技术（入门级），真的只能说“roy”真牛的无话可说！！！赞一个！！