Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网(6)

问题导读：
1、Neutron 如何通过OVS对GRE和VXLAN进行支持？
2、为什么H3C 选择VxLAN？



2. Neutron 通过 OVS 对 GRE 和 VXLAN 的支持

    因为 OVS 对两种协议的实现机制，Neutron 对两个协议的支持的代码和配置几乎是完全一致的，除了一些细小差别，比如名称，以及个别配置比如VXLAN的UDP端口等。OVS 在计算或者网络节点上的 br-tun 上建立多个 tunnel port，和别的节点上的 tunnel port 之间建立点对点的 GRE/VXLAN Tunnel。Neutron GRE/VXLAN network 使用 segmentation_id （VNI 或者 GRE tunnel id） 作为其网络标识，类似于 VLAN ID，来实现不同网络内网络流量之间的隔离。

2.1 Open vSwitch 实现的 VxLAN VTEP

  从上面的基础知识部分，我们知道 VTEP 不只是实现包的封装和解包，还包括：

（1）ARP 解析：需要尽量高效的方式响应本地虚机的 ARP 请求

（2）目的 VTEP 地址搜索：根据目的虚机的 MAC 地址，找到它所在机器的 VTEP 的 IP 地址

通常的实现方式包括：

（1）使用 L3 多播


（2）使用 SDN 控制器（controller）来提供集中式的 MAC/IP 对照表



（一个基于 Linuxbrige + VxLAN + Service Node 的集中式 Controller node 解决 VNI-VTEP_IPs 映射的提议，替代L3多播和广播，来源： 20140520-dlapsley-openstack-summit-vancouver-vxlan-v0-150520174345-lva1-app6891.pptx）

（3）在VTEP本地运行一个代理（agent），接收（MAC, IP, VTEP IP）数据，并提供给 VTEP

那 Open vSwitch 是如何实现这些功能需求的呢？

（1）在没有启用 l2population 的情况下，配置了多播就使用多播，没的话就使用广播

（2）在启用 l2population 的情况下，在虚机 boot 以后，通过 MQ 向用于同网络虚机的节点上的 l2population driver 发送两种数据，再将数据加入到 OVS 流表

    （2.1）FDB (forwarding database): 目的地址-所在 VTEP IP 地址的对照表，用于查找目的虚机所在的 VTEP 的 IP 地址

    （2.2）虚机 IP 地址 - MAC 地址的对照表，用于响应本地虚机的 ARP 请求

详细情况，请参考 （http://www.cnblogs.com/sammyliu/p/4633814.html）
Neutron 理解 (4): Neutron OVS OpenFlow 流表 和 L2 Population [Netruon OVS OpenFlow tables + L2 Population]

2.2 隧道端口 （tunnel port）

    下面是一个实例。该例子中，10.0.1.31 Hypervisor上的 br-tun 上分别有两个 GRE tunnel 端口和两个 VXLAN tunnel 端口，分别连接 目标 Hypervisor 10.0.1.39 和 21。

[mw_shl_code=applescript,true]Bridge br-tun
        Port "vxlan-0a000127"
            Interface "vxlan-0a000127"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.39"}
        Port "vxlan-0a000115"
            Interface "vxlan-0a000115"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"}
        Port "gre-0a000127"
            Interface "gre-0a000127"
                type: gre
                options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.39"}
        Port "gre-0a000115"
            Interface "gre-0a000115"
                type: gre
                options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"}
[/mw_shl_code]

当有多个节点时，Neutron 会建立一个 tunnel 网：



2.3 在不使用 l2population 时的隧道建立过程

    要使用 GRE 和 VXLAN，管理员需要在 ml2 配置文件中配置 local_ip（比如该物理服务器的公网 IP），并使用配置项 tunnel_types 指定要使用的隧道类型，即 GRE 或者 VXLAN。当 enable_tunneling = true 时，Neutorn ML2 Agent 在启动时会建立 tunnel bridge，默认为 br-tun。接着，ML2 Agent 会在 br-tun 上建立 tunnel ports，作为 GRE/VXLAN tunnel 的一端。具体过程如图所示：


OVS 默认使用 4789 作为 VXLAN port。下表中可以看出 Neutron 节点在该端口上监听来自所有源的UDP包：

[mw_shl_code=applescript,true]root@compute1:/home/s1# netstat -lnup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp     3840      0 0.0.0.0:4789            0.0.0.0:*                           -[/mw_shl_code]

2.4 Neutron tunnel 数据流向

    Neutron 中的数据流向是受 Neutron 添加在 integration bridge 和 tunnel bridge 中的 OpenFlow rules 控制的，而且和 L2 population 直接相关。具体内容在下一篇文章中会仔细分析。

2.5 MTU 问题

VXLAN 模式下虚拟机中的 mtu 最大值为1450，也就是只能小于1450，大于这个值会导致 openvswitch 传输分片，进而导致虚拟机中数据包数据重传，从而导致网络性能下降。GRE 模式下虚拟机 mtu 最大为1462。

计算方法如下：

    vxlan mtu = 1450 = 1500 – 20(ip头) – 8(udp头) – 8(vxlan头) – 14(以太网头)
    gre mtu = 1462 = 1500 – 20(ip头) – 4(gre头) – 14(以太网头)

可以配置 Neutron DHCP 组件，让虚拟机自动配置 mtu，官方文档链接 http://docs.openstack.org/juno/i ... n-network-node.html

[mw_shl_code=applescript,true]#/etc/neutron/dhcp_agent.ini
[DEFAULT]
dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf

#/etc/neutron/dnsmasq-neutron.conf
dhcp-option-force=26,1450或1462[/mw_shl_code]

重启 DHCP Agent，让虚拟机重新获取 IP，然后使用 ifconfig 查看是否正确配置 mtu。

3. H3C 选择 VxLAN 的理由

   H3C 是国内领先的网络设备供应商之一，在其 一篇文章 中，谈到了他们为什么选择 VxLAN 技术。这对别的用户具有一定的参考性。

3.1 为什么选择 VxLAN

从Overlay网络出现开始，业界陆续定义了多种实现Overlay网络的技术，主流技术包括：VXLAN、NVGRE、STT、Dove等（如图3所示）。





Overlay主流技术概览（没找到清晰图）

从标准化程度进行分析，DOVE和STT到目前为止，标准化进展缓慢，基本上可以看作是IBM和VMware的私有协议。因此，从H3C的角度来看无法选择这两种技术。

从技术的实用性来看，XLAN和NVGRE两种技术基本相当。其主要的差别在于链路Hash能力。由于NVGRE采用了GRE的封装报头，需要在标准GRE报头中修改部分字节来进行Hash实现链路负载分担。这就需要对物理网络上的设备进行升级改造，以支持基于GRE的负载分担。这种改造大部分客户很难接受。相对而言，VXLAN技术是基于UDP报头的封装，传统网络设备可以根据UDP的源端口号进行Hash实现链路负载分担。这样VXLAN网络的部署就对物理网络没有特殊要求。这是最符合客户要求的部署方案，所以VXLAN技术是目前业界主流的实现方式。

3.2 VXLAN为什么选择SDN

    VXLAN的标准协议目前只定义了转发平面流程，对于控制平面目前还没有协议规范，所以目前业界有三种定义VXLAN控制平面的方式。

方式1：组播。由物理网络的组播协议形成组播表项，通过手工将不同的VXLAN与组播组一一绑定。VXLAN的报文通过绑定的组播组在组播对应的范围内进行泛洪。简单来说，和VLAN方式的组播泛洪和MAC地址自学习基本一致。区别只是前者在三层网络中预定义的组播范围内泛洪，而后者是在二层网络中指定VLAN范围内泛洪。这种方式的优点是非常简单，不需要做协议扩展。但缺点也是显而易见的，需要大量的三层组播表项，需要复杂的组播协议控制。显然，这两者对于传统物理网络的交换机而言，都是巨大的负荷和挑战，基本很难实现。同时，这种方式还给网络带来大量的组播泛洪流量，对网络性能有很大的影响。

方式2：自定义协议。通过自定义的邻居发现协议学习Overlay网络的拓扑结构并建立隧道管理机制。通过自定义（或扩展）的路由协议透传Overlay网络的MAC地址（或IP地址）。通过这些自定义的协议可以实现VXLAN控制平面转发表项的学习机制。这种方式的优点是不依赖组播，不存在大量的组播泛洪报文，对网络性能影响很小。缺点是通过邻居发现协议和路由协议控制所有网络节点，这样网络节点的数量就受到协议的限制。换句话说，如果网络节点的数量超过一定范围，就会导致对应的协议（例如路由协议）运行出现异常。这一点在互联网行业更加明显，因为互联网行业云计算的基本特征就是大规模甚至超大规模。尤其是在vSwitch上运行VXLAN自定义路由协议，其网络节点数量可以达到几千甚至上万个，没有路由协议可以支持这种规模的网络。

方式3：SDN控制器。通过SDN控制器集中控制VXLAN的转发，经由Openflow协议下发表项是目前业界的主流方式。这种方式的优点是不依赖组播，不对网络造成负荷；另外，控制器通过集群技术可以实现动态的扩容，所以可以支持大规模甚至超大规模的VXLAN网络。当然，SDN控制器本身的性能和可靠性决定了全网的性能和可靠性，所以如何能够提高控制器的性能和可靠性就是核心要素。

3.3 VXLAN Fabric网络架构的优势

    云计算网络一直都有一个理念：Network as a Fabric，即整网可以看作是一个交换机。通过VXLAN Overlay可以很好地实现这一理念——VXLAN Fabric（如下图所示）。


Spine和Leaf节点共同构建了Fabric的两层网络架构，通过VXLAN实现Spine和Leaf之间的互联，可以看做是交换机的背板交换链路。Spine节点数量可以扩容，最大可以达到16台。Leaf节点数量也可以平滑扩容。理论上只要Spine节点的端口密度足够高，这个Fabric可以接入数万台物理服务器。

另外，通过VXLAN隧道可以实现安全服务器节点的灵活接入。这些安全服务节点可以集中部署在一个指定区域，也可以灵活部署在任意Leaf节点下。通过Service Chain技术实现任意两个虚拟机之间可以通过任意安全服务节点互联。保证网络中虚拟机业务的安全隔离和控制访问。同理，Fabric的出口节点也可以部署在任意位置，可以灵活扩展。

简而言之，VXLAN Fabric构建了一个灵活的、稳定的、可扩展的Overlay网络。这个网络可以有效地解决云计算对网络的挑战，是云计算网络发展的趋势。


来源：http://www.cnblogs.com/sammyliu/p/4627230.html

相关内容：


neutron系列：Neutron 所实现的虚拟化网络(1)

neutron系列：Neutron 所实现的虚拟化网络(2)

neutron系列：使用 Open vSwitch + VLAN 组网(3)

neutron系列：使用 Open vSwitch + VLAN 组网(4)

Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网 (5)

Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网(6)

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(7)

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(8)

Neutron系列 : Neutron 是如何向 Nova 虚机分配固定IP地址的(9)

Neutron系列 : Neutron 是如何向 Nova 虚机分配固定IP地址的(10)

Neutron 系列 (11): Neutron 是如何实现负载均衡器虚拟化的【基础篇】

Neutron 系列 (12): Neutron 是如何实现负载均衡器虚拟化的【提高篇】

Neutron 系列 (13): Neutron 是如何实现虚机防火墙的 【上】

Neutron 系列 (14): Neutron 是如何实现虚机防火墙的 【下】

Neutron 系列 (15): OpenStack 是如何实现 Neutron 网络 和 Nova虚机 防火墙的

Neutron 系列（16）：虚拟专用网（VPN）虚拟化

Neutron 系列 (17): Neutron 分布式虚拟路由【上】

Neutron 系列 (18): Neutron 分布式虚拟路由【下】

Neutron系列（19）：Neutron L3 Agent HA 之 虚拟路由冗余协议（VRRP）【上】

Neutron系列（20）：Neutron L3 Agent HA 之 虚拟路由冗余协议（VRRP）【下】

Neutron系列（21）：OpenStack 高可用和灾备方案 [OpenStack HA and DR]【上】

Neutron系列（22）：OpenStack 高可用和灾备方案 [OpenStack HA and DR]【下】