关于VXLAN与异构云之间的集成

问题导读

1.VXLAN的技术本质是什么呢？
2.VXLAN的都有哪些缺点？








          我们知道，IBM最近收购了SoftLayer公司，SoftLayer是一个有些年头的数据中心，以前没有云的概念，所以它主要是通过裸机来提供服务，后来有了CloudStack就开始用CloudStack，今后也将支持OpenStack。那么SoftLayer看起来更像一个API网关，在CloudStack和OpenStack两类云中部署虚机。但是今天上午我一直在想一个需求，即使它通过API网关可以在两类云中部署虚机，但两类云中的虚机从网络上不能互通啊。所以我一直在想能不能通过SDN像OpenDaylight之间的技术解决这个问题。

         我之前听说过VXLAN这个名词，但仅仅是知道这么个名词而已，它究竟是干什么的我并不清楚。在下午的google search中，居然发现VXLAN就是来解决我这类需求的。原来是有这类技术的，呵呵想法撞车了看来我专利的想法泡汤了。


         那么我们来谈谈VXLAN的技术本质是什么呢？
         1）首先它和SDN的思想一样通过重新自定义帧格式，采用基于2.5层UDP的socket走3层将这种自定义的2层帧跨数据中心传过去再解析出来。
         2）在这种自定义帧中可以加入原有的VLAN和tenant的概念来隔离网络，这个vlan的大小可以轻易突破0-4094的限制。
         3）这样的好处是虚机可以跨数据中心迁移。
         4） VMware是通过这种软件的VXLAN方式来解决这类问题；Cisco玩硬件的它当然通过硬件的方式来解决，但原理是一样的也是Mac in IP的方式；
微软又搞了一个标准NVGRE，一样的故事，但区别在于VXLAN是VMware更私有的封装，NVGRE的封装采用了标准的GRE遂道，但GRE的性能可能是一个问题。
         5) IBM也有类似的产品Dove, Dove的遂道协议是私有的，但它使用VXLAN的帧格式进行封装，这意味着它可以支持任何VXLAN的底层网络硬件。Dove的那个虚拟交换机名称叫DVS5000v, 参考http://www.ileader.com.cn/html/2012/11/28/57227.htm




           下面是VXLAN的示意图：





             下面说说VXLAN的缺点，
         对于实现更为动态和更具可扩展性的私有云网络而言，VXLAN和NVGRE的出现是一个很大的进步，但是它们也不是完整的解决方案。它们是封装的协议，还不具备控制面板。相反，它们还依赖于其他的网络功能。例如，VXLAN依赖于与协议无关的多路广播(UDP PIM)，而且建立VM之间的通信必须通过2层淹没和动态MAC地址学习实现

　　 而且，VXLAN和NVGRE还无法解决在核心网络扩展2层域所面对的基础问题：“网络长号”。即使两个VM位于同一个交换机上，流量仍然需要先转发到核心网络，然后到达目的地，感觉就像是乐器长号的管子一样。这就像是在使用学生火车优惠票一样，原先住在城市A，后来搬家到城市B，但是如果一定要享受优惠，您也只能先买到城市A的票，然后再去新家所在的城市B。这样的架构效率很低，而且无法扩展。最后，VXLAN是一个虚拟结构，无法连接到一些物理设备，如防火墙、负载均衡器等。关于这个问题，目前已有VXLAN网关产品来解决，它能把负载均衡和防火墙这样的网络服务扩展到VXLAN流量中。网关的作用在于解封闭和重新封闭，在数据中心到云环境，需要检查WAN优化，应用交付控制器、防火墙，入侵防御和入侵检测，没有人能够预见VXLAN流量的发展，所以须在所有地方建立网关。所以Vxlan网关用于实现VXLAN的Overlay流量与传统的以太网数据流量之间的封装与解封装过程(一是剥离/封装VXLAN,　二是映射VXLAN-VLAN)，因为VXLAN网络的VTEP功能点本身就是VXLAN的封装与解封装隧道点，因此VXLAN Gateway首先需要具备VTEP功能，形态可以是vSwitch、物理交换机等，只是对于网络中的虚机或其它设备地址表项的处理有所差异(见: 基于多租户的云计算Overlay网络)

        关于openflow，它并不是像传统网络那样一层层剥包抽取出MAC在L2层转发，抽取出IP在L3层转发。它是根据：端口号、VLAN、L2／L3／L4信息的10个关键字在控制器层通过字符串匹配进行转发的，所以openflow并不是传统上的L2层设备。特别是，对于L3设备，各类IGP／EGP路由也是运行在OpenFlow Controller之上的。它处理L2层的转发好理解，它怎么和L3层的这些路由设置打交道呢，它怎么与运行VLAN、MPLS，以及BGP、OSPF 和IS-IS等路由协议的传统以太网交换机和谐共存呢？

这里有一篇论文http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf ， 目前的OpenFlow能够实现对L2-L4层字段的转发。由于OpenFlow是通过软件实现对整个网络的控制，因此包括BGP协议这些所谓的“控制”功能，理论上都是能够在控制器上通过软件方式实现的，不过目前尚没有看到这样的软件，因为传统的路由信息表和控制器管理的全局网络信息之间需要如何转换，都是跟特定的控制器相关的，而不同的控制器存储的网络全局信息有可能是不一样的。觉得根源在于目前SDN的北向接口还未标准化，各个控制器的API标准未统一。

       谷歌的这篇论文（https://www.opennetworking.org/images/stories/downloads/sdn-resources/customer-case-studies/cs-googlesdn.pdf），其实它里面就实现了BGP协议，不过它不是直接通过控制器软件实现，而是通过Quagga实现对BGP报文的处理从而生成RIB，然后通过控制器Onix上开发的软件RAP实现RIB(路由转发表）前缀到NIB（openflow转发表的名字）的转换。OpenFlow交换机没有任何“控制”功能，所有的控制逻辑都在控制器上实现，明白这一点就很好理解它怎么和L3层交互了。通过OpenFlow实现两个数据中心L2层网络互通，貌似能够通过FlowVisor实现(FlowVisor是用来管理多个openflow控制器的），不过会增加网络部署的复杂度了. 可参考这篇文章《Inside Google's Software-Defined Network，http://www.networkcomputing.com/ ... d-network/240154879）









对上图的相关解释如下：

1, Network Controller Servers (NCSs)
2, ISIS是类似于OSPF的一种基于路径状态的内部路由协议
3, Paxos是一个分布式一致性算法的协议
4, Quagga是一个实现了像RIP，OSPF， BGP等动态路由算法的软件，它可以动态地学习BGP报文生成路由规则表RIB
5, RAP是google基于google的openflow controls (Onix，也即上面的NCSs)的一个软件，用于将RIB生成NIB（openflow的转发表），这样openflow switch根据它作转发。


不过上面的路由转发完全不同于传统的包转发，而是基于流转发的，那么具体到openstack中，它怎么和l3-agent协作呢？还是另起灶炉？



再科普一下BGP的两种邻居IBGP和EBGP：

BGP在路由器上运行主要有两种邻居:IBGP（Internal BGP）和EBGP（External BGP）。如果两个交换BGP报文的对等体属于同一个自治系统，那么这两个对等体就是IBGP对等体（Internal BGP），如果两个交换BGP报文的对等体属于不同的自治系统，那么这两个对等体就是EBGP对等体 （External BGP）。






如上图所示，RTB和RTD为IBGP对等体，RTA和RTB是EBGP对等体。

虽然BGP是运行于自治系统之间的路由协议，但是一个AS的不同边界路由器之间也要建立BGP连接，只有这样才能实现路由信息在全网的传递，如RTB和RTD，为了建立AS100和AS300之间的通信，我们要在它们之间建立IBGP连接。

IBGP对等体之间不一定是物理上直连的，但必须保证逻辑上全连接。（TCP连接能够建立即可）。为了IBGP对等体路由通告的可靠性，我们一般都是采用loopback接口建立IBGP邻居关系，同时必须指定路由更新报文的源接口。

peer { group-name | peer-address } connect-interface interface-name
一般的路由器（包括Quidway系列路由器）都默认要求EBGP对等体之间是有物理上的直连链路，同时他们一般也提供改变这个缺省设置的配置命令。允许同非直连相连网络上的邻居建立EBGP连接。

peer { group-name | peer-address } ebgp-max-hop [ ttl ]
EBGP的邻居要求必须是直连的（除非做了特别的配置），
而IBGP不必非要是直连的（因为它使用TCP协议且单播），这样RTB通过EBGP收到RTA的路由信息之后，只会将这些路由信息发往RTD，RTD到发给RTE。



         我的一些关于SDN的暂不清晰的不成熟想法：

      1)基于sFlow的VXLAN流量分析工具？
        2) 基于OpenVswitch中的VXLAN的三层来做WAN的异构云（像openstack和cloudstack）的集成，再上之上整一个TE（Traffic Engine)，参见谷歌的论文，
            Inter-Datacenter WAN with centralized TE using SDN and OpenFlow,https://www.opennetworking.org/images/stories/downloads/sdn-resources/customer-case-studies/cs-googlesdn.pdf
           或者用Dove ？
        3）具有网络感知能力的应用能够根据需要对逻辑网络进行动态定义的应用
        4）流量工程ECMP， 怎么能实现GRE遂道的多路径传输？
        5）VXLAN之类的流量可视化工具？
        6) 在openstack neutron中集成VXLAN网关？
        7) 基于vxlan的异构云集成？目前openstack有vxlan插件，但云一般有三层网络（虚机用的服务网络，物理机用的管理网络，外网网络），现有的vxlan插件应该是将两端的物理机的管理网络IP作为遂道的端点的，但如果跨数据中心的话，我觉得应该再给物理机分一个浮动IP作为遂道端点， 但是浮动IP是加在网络结节上的，可行吗？想法未验证）


       也附一篇文章，有关 OpenFlow/SDN 的小总结 http://richardzhao.me/?p=775




附录，
1）OpenVswitch使用GRE的命令：
ovs-vsctl add-port br0 tep0 -- set interface tep0 type=internal
ifconfig tep0 192.168.1.11 netmask 255.255.255.0

ovs-vsctl add-int br2 gre0 -- set interface gre1 type=gre options:remote_ip=192.168.1.11
ovs-vsctl add-int br2 gre0 -- set interface gre1 type=gre options:remote_ip=192.168.1.10

2) linux bridge中的vxlan

brctl addbr br.4090

ip link add vxlan4090 type vxlan id 4090 group 239.1.1.1 dev eth0

ip link set vxlan4090 up

ip link set br.4090 up

brctl addif br.4090 vxlan4090

然后将虚机的tap设备插入到上述网桥即可.

3） OpenVswitch中使用VXLAN的命令：
ovs-vsctl add-int br2 vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.1.10
ovs-vsctl add-int br2 vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.1.11

参见资料：http://blog.scottlowe.org/2013/05/07/using-gre-tunnels-with-open-vswitch/




像GRE，VXLAN这类overlay的遂道都有一个很大的重要，它在虚拟层面将Ｌ２层打通了，如果再采用广播来做ＡＲＰ的话可能会造成广播风暴，所以可以采用ARP Proxy的方式自己用程序实现cache来给虚机提供ip到mac的映射。另一方面也可以使用其他overlay的技术，如STT，它不使用广播，它也是一种mac over ip的协议，和vxlan, nvgre类似，都是把二层的帧封装在一个ip报文的payload中，在ip报文的payload中，除了虚拟网络的二层包以外，还要把构造的一个tcp头（这样硬件网卡误以为它是一个TCP包，这样就会用硬件来分片了，这是STT的最大优点），和一个stt头加在最前面。见：http://tools.ietf.org/html/draft-davie-stt-01, NTT与VXLAN的区别见：http://blog.ipspace.net/2012/03/do-we-really-need-stateless-transport.html




作者：张华  ( http://blog.csdn.net/quqi99 )