“VXLAN 来了，Open Flow 前景如何？”有38个回复

1. interbeing 于 2011-09-01 5:15 下午

   起码要四层设备来做这个封包的动作了。不知道效率怎么样。一般的broadcom的芯片能不能干这事?

   这个想法很简单，怎么以前没人提？

2. interbeing 于 2011-09-01 5:26 下午

   看到说cisco 1.5 release of Nexus 1000V (entering beta in September 2011).

3. 根本不相干 于 2011-09-01 6:37 下午

   这恰恰对open vswitch所倡导的理念是利好啊

   首先L2 over L3，是从根本上对所谓大二层的颠覆。网络回归本质：简单的大容量L3管道，不去识别什么虚拟化，所有的虚拟化功能在边缘搞定。

   目前openvswitch流表转发，本来就支持多种L2 over L3方式(这是vmware vds所欠缺的)，包括Ethernet over GRE, CAPWAP, IPsec, GRE over IPsec等，现在只不过多增加一种隧道封包格式而已，架构上是天然亲和的。

4. 根本不相干 于 2011-09-01 6:43 下午

   这个评论与我心有戚戚焉，请注意看最后三段

   ———————–
   转帖：VXLAN: Moving Towards Network Virtualization
   Author: networkheresy

   If you missed it, VMware, Cisco, Broadcom and others announced support for VXLAN a new tunneling format. For the curious, here is the RFC draft.

   So quickly, what is VXLAN? It’s an L2 in L3 tunneling mechanism that supports L2 learning and tenancy information.

   And what does it do for the world? A lot really. There currently is fair bit of effort in the virtualization space to address issues of L2 adjacency across subnets, VM mobility across L3 boundaries, overlapping IP spaces, service interposition, and a host of other sticky networking shortcomings. Like VXLAN, these solutions are often built on L2 in L3 tunneling, however the approaches are often form-fitted and rarely are they compatible with another implementation.

   Announcing support for a common approach is a very welcome move from the industry. It will, of course, facilitate interoperability between implementations, and it will pave the way for broad support in hardware (very happy to see Broadcom and Intel in the announcements).

   Ivan (as usual, ahead of the game) has already commented on some of the broader implications. His post is worth a read.

   I don’t have too much to add outside of a few immediate comments.

   First, we need an open implementation of this available. The Open vSwitch project has already started to dig in and will try and have something out soon — perhaps for the next OpenStack summit. More about this as the effort moves along.

   Second, this is a *great* opportunity for the NIC vendors to support acceleration of VXLAN in hardware. It would be particularly nice if LRO support worked in conjunction with the tunneling so that interrupt overhead from the VMs is minimized, and the hardware handles segmentation and coalescing

   Finally, it’s great to see this sort of validation for the L3 fabric, which is an excellent way to build a datacenter network. IGP + ECMP + a well understood topology (e.g. CLOS or Flattened butterfly) is the foundation of many large fabrics today, and I predict many more going forward.

5. 根本不相干 于 2011-09-01 6:59 下午

   另外，推荐这三篇关于网络虚拟化实现方案比较的系列文章，我个人很欣赏，老外的笔头就是比我好，呵呵。

   我自己感到最有共鸣的观点：
   1) vswitch要offload到edge switch，是Cisco等网络设备商的FUD策略
   2）vswitch可以offload的NIC，但一定是stateless的简单处理，不建议一股脑上去把NIC做成另一个NP

   http://networkheresy.wordpress.com/2011/07/10/the-rise-of-soft-switching-part-3-a-perspective-on-hardware-offload/

   http://networkheresy.wordpress.com/2011/06/25/the-rise-of-soft-switching-part-ii-soft-switching-is-awesome-tm/

   http://networkheresy.wordpress.com/2011/06/14/the-rise-of-soft-switching-part-i-introduction-and-background/

6. 根本不相干 于 2011-09-01 7:05 下午

   晕，带链接要审核，重发

   另外，推荐这三篇关于网络虚拟化实现方案比较的系列文章，我个人很欣赏，老外的笔头就是比我好，呵呵。

   我自己感到最有共鸣的观点：
   1) vswitch要offload到edge switch，是Cisco等网络设备商的FUD策略
   2）vswitch可以offload的NIC，但一定是stateless的简单处理，不建议一股脑上去把NIC做成另一个NP

   链接发不出来，大家自己找吧。
   域名是networkheresy DT wordpress DT com，
   进7月博文目录，是第三篇The Rise of Soft Switching Part III: A Perspective on Hardware Offload。里面有链接到1/2

7. Lucien 于 2011-09-01 9:09 下午

   所谓的VXLAN就是L2 tunnel？

   有点意思

8. 理客 于 2011-09-01 10:32 下午

   TCP/IP更多的是engineering，里面的创意多无技术难度，只要你敢想，无论是傻的还是聪明的，比如MAC IN MAC，也许这也是TCP/IP能够普及，能够迷倒粉丝一片的地方
   如果是在服务器上做MAC over UDP，就和承载网络无关了，也是一个不错的创意
   如果是在网络边缘做这个封装，比服务器直接封装要麻烦多了。
   一般看来，如果网卡能以很低的成本支持，在服务器实现更好，但综合考虑到TCO，未必服务器实现就更好，这个方案要达到批量商用，考虑到现网设备，还不那么容易

9. ykzj 于 2011-09-02 6:02 上午

   四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层再封到四层中的二层

10. nalinaly 于 2011-09-02 7:53 上午

    8楼说的深得我心，有时候自己都会在TCP/IP的基础上想点东西出来，但是因为对硬件软件应用整体不熟，完全不知道可行性如何，别人忽悠出一个概念出来也只好跟着去相信…

11. HJ 于 2011-09-02 1:04 下午

    这又回到了那个老问题，到底是把智能放在主机，还是放在网络。

    不同阵营的人有不同的观点

12. infoblox 于 2011-09-02 2:24 下午

    刚从vmworld回来，看来vmware虽然是openflow的成员，但是根本心猿意马，是下决心要推VXLAN了。我问了几个presenter关于VDS是否将支持openflow的问题，都是避而不答。这对openflow的发展还是一个不小的影响。我老板现在参与openflow工作组的会。他说CISCO对openflow很有些pissed off。因为主要是G，F，Y这些互联网公司说了算。看来要和vmware一起另立山头了。

13. CF 于 2011-09-02 8:43 下午

    其实对G，F,Y来讲未必不是好事，还是SDN，只不过专心投入在open VSwitch层就行了，外部网络只要傻快就行…

14. russellw 于 2011-09-02 9:01 下午

    几个疑问：
    1、OTV是CE Based Soulution，不需要运营商支持，VxLAN做Inter-DC方案时需要运营商网络支持并开放Multicast，部署存在难度。
    2、通过封装的UDP隧道中增加的24bit Tag解决了2^12 VLAN ID的限制，但是需要网络支持2^24 multicast组来支持MAC学习，是否把难题转移到了组播上？
    3、我不觉得和OpenFlow有直接的关系，openflow试图通过软件的灵活性对网络编程来提供各种解决方案，vxLan不过是提供了另外一种技术，虽然讲如果DC的需求被现有的技术更好的实现会降低OpenFlow商用的迫切性。领先的Hardware Switch Vendor不可能喜欢OpenFlow，他们总是希望能够绑定客户，卖出更多的硬件，因此昨天有OTV、LISP+OTV，今天有VxLAN，明天还会有别的解决方案。

    抛开OpenFlow不谈，我觉得SoftSwitch+Directory Based Address Resolution可能更加适用于数据中心，无论是用L2隧道还是L3隧道。中心化的Directory Server可以避免MAC学习带来的广播/组播开销，也更加利于实现VM移动性。SoftSwitch也使得网络新特性的支持非常简单，并且X86 Core的成本比Hardware Switch更低

15. 根本不相干 于 2011-09-02 10:34 下午

    楼上理解很到位

    openflow和vxlan没有直接关系。一个是实现架构，一个是隧道封装格式，不是一个维度。

    在nicira主导的openvswitch项目中，仅仅是用了openflow流表驱动转发fastpath(对标准of做了很大扩展)，以解决标准linux stack在虚拟、动态环境下的性能低下。OVS是一个纯softswitch+集中Directory方案，根本没试图用OF去控制网络switch设备，它的Directory就是OVSDB。

    Directory Server与softswitch是天作之合，也是softswitch方案的独特优势。其它任何基于network gear的方案，不论TOR还是edge switch，在引入Directory server时都会碰到域间集成带来的管理复杂性。而不引入Directory Server，就需要带内解决控制面问题，不论是Trill/AQ还是Vxlan，都不得不把虚拟层信息map到网络中的组播上，结果更复杂。

    Cisco自己也承认，OTV和vxlan封装格式没有本质差别。但vxlan相比之下控制面更为完善，当然对网络也提出了更高的要求。因此vxlan是站在cisco卖设备角度所必需的立场。但站在IAAS solution角度，softswitch based OTV + 集中DirServer却更简洁，但不符合网络设备商利益。

    事实上，OVS的GRE封装，与OTV的GRE封装就大同小异，当然OTV还支持UDP。考虑到某些场景下UDP比GRE有更好适应性，因此建议OVS下一步也支持UDP封装，这应该是顺手拈来的事情。（它目前已经支持CAPWAP，GRE over IPSEC等格式）

    ——————————

    Working with OTV and LISP

    VXLAN is intended for creating more logical networks in a cloud environment. Overlay Transport Virtualization (OTV) while using similar frame format as VXLAN, is a data center interconnect technology extending Layer 2 domains to different data centers over Layer-3. Unlike VXLAN, OTV has simpler deployment requirements since it does not mandate multicast-enabled transport network. Locator ID Separation Protocol (LISP) goes a step further by providing IP address mobility between data centers with dynamic routing updates. While VXLAN, OTV, and LISP may share similar frame format, they serve very different networking purposes and are hence complimentary to each other.

16. Da Vinci 于 2011-09-03 3:08 上午

    不解VXLAN和OF有什么关系。帖子本身没啥意思，回复的内容倒是挺不错。

17. Lucien 于 2011-09-04 10:13 下午

    14楼是否可以详细讲解下OTV如何包含UDP信息？据我所知，OTV是一个MAC in IP的技术，应该不会涉及到四层，个人觉得搞到四层也没啥用啊。

    虽然OTV封装里面有8 Byte的OTV shim字段，有放UDP的潜力。

    这样想，LAN1内部发往一个属于LAN2的MAC地址，然后LAN1的edge把LAN2的edge的IP封装进来，然后LAN2收到这个包以后就把LAN1 edge的封装全部去掉。这个过程中，UDP会有用？

18. 根本不相干 于 2011-09-05 2:34 上午

    早期OTV是GRE封装，就是你提到的那个8B的shim，后来OTV增加了UDP封装。具体去cisco网站搜索一下吧，没搜到的话，等我回头有空了把链接贴上来

19. Lucien 于 2011-09-05 4:16 上午

    呵呵，的确没有找到。

    相信不相干兄是正确的，但是还是不能理解，要UDP来干什么。因为OTV的封装在LAN edge口上已经扔掉，也就是说只有LAN交换机的入口才能看到UDP，host根本看不到。

    关于这点，不相干兄有何见解？

20. 清华土著 于 2011-09-05 11:37 下午

    vxlan没有controller，没有全局映射。
    于是所有信息都携带在新加的超过40字节的包头上。ARP的学习实际依然是广播，仅通过路由器组播进行了限制。

    未提及部署及初始化的事情，可能需要一个或多个vCenter去协同每个hypervisor。网络交换的控制权分摊在hypervisor和路由器上，缺一不可。

    总之，就VXLAN目前的应用来看，这个方案的成本和复杂性都过高了。不过40多字节的头部，将来做某些应用扩展，或许会有用。

    PS: 以上文字通过FIT某OpenFlow网络发送。我们采用自己设计的VL2网络。No new protocol, no additional header, just intelligent mapping schemes.

21. 理客 于 2011-09-06 12:42 上午

    清华土著是openflow等领域的大牛，坚持下去，必有所成

22. 老韩 于 2011-09-06 9:14 上午

    要把产品Show出来，几句话不管用。建议清华土著照着WeConnect的视频做上一段。

23. archerlu 于 2011-09-07 11:04 下午

    简单看了下VXLAN的草案，好像是把Vswitch都加入同一个组播组吧？并不是14所说的需要2^24 multicast组。不知道我的理解对不对

24. 小瑞 于 2011-09-09 7:15 下午

    其實VXLAN的提出, 對市場是有一定正面度的. 因為這原本就是數據中心最痛的問題, 這一提出, 其實就已經是正視了這個問題. 關於這三間的動作我覺得挺好的. 只是仔細一看這draft, 就頭大了..
    1) 結構概念幾乎跟以前的TRILL大同小異, 且一定得使用multicast去建立control panel的網絡ˋ. 這對不是營運商的跨物理的數據中心就給了一個大限制
    2) 支援24 bits的二層虛擬網數目, 端點的探索還是需要multicast上的找尋, 這包的量別說是24 bits的網, 光12 bits數量的網可能都是頭痛的問題
    3) Tunnel數據的建立是根據UDP, 掉包的錯誤修正怎做？只用checksum bit =0 或不等0來判斷數據結構完整, 這風險挺大的

    這還需要多多的調研一下, 畢竟 這看起來還是舊瓶新裝包裝手法, 只是擴大應用了, 作法跟豐田汽車改款的方式挺像的

25. ayvuir 于 2011-09-12 5:32 下午

    to 小瑞: 不用tunnel错包丢包本来就不会修正，用了tunnel错包丢包的概率也不会提升，这个不算一个问题

26. 小瑞 于 2011-09-14 8:15 上午

    感謝25樓大哥的提醒, 因為在VXLAN的Drift裡提到, Checksum bit=0 等於數據完整, 不等0=數據錯誤.. 這其實很容易就判斷出來了, 但是就如你說的, 這是個UDP的基礎, 掉包/錯包 修正怎做..這是看不明白的

27. 愤怒的小鸟 于 2011-09-15 7:13 下午

    对VXLAN，不知道那些唱赞歌的考虑过数据中心中的防火墙该如何配置？负载均衡器如何配置？IDS怎么办？我买他们的东西，就象上了钩的鱼一样。你认为 Microsoft 会和 VMware 一起来做这个标准吗？

28. Bright 于 2011-09-19 1:38 上午

    1. 其实没这个也可以通过vrf的方式实现，只不过与VXLAN相比”革命”的没那么彻底(扩展性弱)
    2. VTEP具体如何落地是关键(软的方式效率低，硬的方式看标准化和市场接受度了)
    3. 承载网依赖组播较强(单个数据中心看网络设备的组播处理能力了，DCI就要看运营商提供的链路能否让跑组播了)
    4. 安全性(毕竟L3更容易受攻击和snooping，而安全很多时候是消耗资源的服务，所以最后要看安全的设计思路了)

29. 理客 于 2011-09-19 3:09 上午

    L2和L3在安全性方面，L2应该弱多了

30. CF 于 2011-09-20 1:53 上午

    to 27楼，
    M$oft 刚提出了 NVGRE，另立山头:

    http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00

31. igp2bgp 于 2011-10-31 11:50 上午

    mark, 学习一下， 感觉VxLAN有点类是ROSEN,VTEP如果不参与signalling的话，效率有点问题，如果跑的话，如何scale?

32. OpenFLOW 于 2011-12-14 12:30 上午

    最近在看openflow。

33. Interop_LasVegas_2012 于 2012-06-07 6:29 下午

    都说说今年的interop呀，好像和去年没啥2样的感觉。
    另外，有了解Nicira这家的没？说说

34. lin_victor 于 2012-11-14 5:51 上午

    拜读啊，这是什么网站11年就在讨论了啊

35. mpc8240 于 2012-12-17 1:55 下午

    回 根本不相干@5楼：
    The Rise of Soft Switching is a great read!
    我是怀着朝圣的心情拜读的，不过读完反而觉得soft switching不过尔尔。
    如果是一个Server内部VMs之间的通讯，vswitch可以做short cut，和外部的通讯用vswitch有什么优势呢？就是因为是纯软件的缘故，推新业务快而已。还有就是软件比TCAM based硬件switch便宜。但这个网络业务的复杂性变不了，唯一的改变就是复杂性从top-of-rack switch转移到vswitch。
    想想看无论SP还是Enterprise，作为严肃的用户，哪个不是对任何新业务、新设备严加测试，然后才敢真正投入使用？用tor switch，至少网络和服务器业务是分离的。用vswitch，网络软件有问题恐怕连服务器业务一块端了。
    我很好奇，哪位指教一下有多少用户真的部署了Nicira的NVP/vswitch了？

36. mpc8240 于 2012-12-17 2:07 下午

    并且vswitch真的那么便宜么？想想看，每个Server都必须run vswitch，相反一个tor switch可以带多少个Server？
    tor switch一般two for each rack，互为备份，软／硬件升级都可以不影响业务。vswitch的upgrade可真的是个麻烦。

37. ABC 于 2012-12-21 7:57 下午

    回复楼上几个兄弟的问题吧.
    弯曲已经几年了,人越来越多,也越来越少了.前沿的东西偶尔能冒一下下,但大多还是老帖子来回定.
    应该还是有不少老人来这里逛逛,发发评论.仅此而已了.
    首席啊,这一亩三分地你老还乐意耕不?

38. DOVE 于 2013-01-30 2:02 上午

    VXLAN需要路由器组播支持，IBM推出的Distributed Overlay Virtual Ethernet (DOVE)感觉更好一些