云网络

因工作需要， 尝试分析主流公有云外网IP是否具有较好的隔离性，以下记录下分析结果。 主流厂商方案调研 aws aws的实例可获得一个动态的public ip（重启后会变）以及不变的elastic ip，这两种ip官方文档上明确给出是属于1:1 NAT，在vm内部仍只能看到私有网地址，使vm只能访问内网及外网，不能向同外网子网的机器注入广播报文，具有较好的隔离安全性。 aws的私有网（即EC2-VPC）做了较多的限制，在FAQ中明确给出不支持组播及广播，在网络上也看到有其他基于第三方软件规避此问题的方案。 aws的网络实现经由了EC2-Classic到EC2-VPC的转变，目前主推EC2-VPC，提供虚拟子网功能。 相关资料： https://aws.amazon.com/articles/1346 https://aws.amazon.com/vpc/faqs/?nc1=h_ls https://www.ravellosystems.com/blog/advanced-enterprise-networking-in-aws-ec2/ https://www.lisenet.com/2014/create-and-attach-a-second-elastic-network-interface-with-eip-to-ec2-vpc-instance/ microsoft azure azure具有两种创建虚拟机模式，注册了试用账号，并结合文档，总结外网在不同模式下实现如下： Azure Resource Manager(v2版本，以资源方式管理一组vm): 默认动态外网ip，可配置成静态外网ip(需关机重开机) ；此种模式下无法动态或静态ip，在内部只能看到一个内网ip的接口。 Azure Service Management(v1版本，称为classic deployment，以服务方式管理一组vm)：默认无外网ip，需通过service的vip对外呈现，需要手工打开vip端口，并关联后端vm dip端口；可设置实例级别的外网ip，称为ilpip，vip本身在vm内部无网卡，ilpip也同样无网卡。 也即无论是v1/v2版本的部署模式，无论是共享的vip还是独立的public ip或ilpip，在vm内部均不可见，类似于floating ip技术，即vm只能访问内网及外网，不能向同外网子网的机器注入广播报文，具有较好的隔离安全性。 而对于私有网，二层做了大量的限制，比如收方向收不到不是到自己地址的报文（含L2/L3过滤），对ARP及DHCP进行了速率限制且做了spoofing处理，组网、广播、udp组播明确表明不支持（详见下附资料）。 相关资料： https://azure.microsoft.com/en-us/documentation/articles/virtual-network-ip-addresses-overview-arm/ https://azure.microsoft.com/en-in/documentation/articles/virtual-networks-faq/ https://blogs.msdn.microsoft.com/igorpag/2014/09/28/my-personal-azure-faq-on-azure-networking-slas-bandwidth-latency-performance-slb-dns-dmz-vnet-ipv6-and-much-more/ https://blogs.msdn.microsoft.com/mast/2016/02/04/azure-networking-public-ip-addresses-in-classic-vs-arm/ google cloud engine 从GCE的官方文档来看，其实例的external public ip基于NAT实现，即vm只能访问内网及外网，不能向同外网子网的机器注入广播报文，具有较好的隔离安全性。 其子网仅支持IPv4单播，不支持IPv4组播及广播，而其资料上提到子网内ARP通过代理予以回复，综合来看，二层组播及广播显然不支持，且在其网络中，也不会存在未知单播的情况。 GCE的网络实现与AWS类似，经由了legacy network到subnet network的变化。 相关资料： https://cloud.google.com/compute/docs/networking aliyun 根据资料及试用结果，aliyun classical network中云主机具有两个接口，外网接口（/22）直接暴露给用户，通过tcpdump可以监听到来自于其他节点及网关的ARP请求，说明未做了隔离，而VPC网络则进行了改进，云主机只有一个接口，外网采用1:1 NAT实现，在vm内部仍只能看到私有网地址，使vm只能访问内网及外网，不能向同外网子网的机器注入广播报文，具有较好的隔离安全性 aliyun同样经过了classic network到VPC网络的改进。 相关资料： http://docs-aliyun-com-cn-b.oss-cn-hangzhou.aliyuncs.com/vpc/pdf/vpc_faq.pdf http://blog.chinaunix.net/uid-28212952-id-5153991.html ucloud 根据上次在为上海客户基于ucloud临时搭建的操作经历，以及Ucloud所公开的设计细节，其EIP同样采用1:1 NAT实现，在vm内部仍只能看到私有网地址，使vm只能访问内网及外网，不能向同外网子网的机器注入广播报文，具有较好的隔离安全性。 相关资料： http://www.infoq.com/cn/articles/UCloud-Sixshot-1 tencent cloud 根据在腾讯云主机的实际验证，linux云主机内部仅有一个接口，具有一个/18子网的内网地址（10.X.X.X），且根据其资料所示，腾读云方外网IP同样采用1:1实现，使vm只能访问内网及外网，不能向同外网子网的机器注入广播报文，具有较好的隔离安全性。 腾讯云EIP 15年底发布，之前与aliyun一样，仍是实例级的额外接口配置公网IP，相当于经过了优化。 相关资料： ...

网络技术这个行业里，厂商通常会对一些技术做出高大上的包装，像网卡VXLAN offload这种技术，就是一个典型的例子，然而其底层技术，也许并不像想象中的那么神秘。 做为网络交换机的开发人员，近年来一直从事数据中心网络虚拟化的相关工作，最近读取一篇关于青云SDN 2.0的文章，里面提到了采用网卡VXLAN offload这种技术后overlay情形下的虚拟网络性能得到了较大规模的提升，考虑到后续我亦将加入云计算公司进行网络虚拟化相关的研发，自然也十分想了解这种技术的底层实现如何，以便从理论上分析其性能是否具有较大的价值。 分析之前，稍微VXLAN的封装格式进行简单的说明，本质上VXLAN类似于一种l2vpn技术，即将二层以太报文封装在udp报文里，从而跨越underlay L3网络，实现不同服务器或不同数据中心间的互联，其格式总结如下： |ETH_HEADER|IP_HEADER|UDP_HEADER|VXLAN_HEADER|INNER_ETH_HEADER|INNER_IP_HEADER|…| 在采用VXLAN技术后，由于vm/docker的报文被封装于外层的UDP报文中予以传输，使得以往的TCP SEGMENT OPTIMIZATION、TCP CHECKSUM OFFLOAD等功能对于内层VM的TCP数据收发失效，较大地影响了VM间通信的性能，给最终用户带来了很差的用户体验。 下面我们来看看不同的方案都是如何实现的： 支持Overlay的交换机 目前较新的万兆交换机大多支持Overlay功能，即支持将以太报文封装在VXLAN报文中予以转发，也即将VXLAN封装功能放在专用的网络设备上，来提供确定性的线速转发性能，但这很明显增加了交换机与服务器之间的耦合，给管理维护带来了一定的复杂度。 NIC VXLAN OFFLOAD 而网卡VXLAN offload则不像Overlay交换机那样要求对组网方案进行较大的变更，而是对于网卡的能力进行了增加，与网卡驱动配合，使得网卡能够知晓VXLAN内部以太报文的位置，从而使得TSO、TCP CHECKSUM OFFLOAD这些技术能够对内部以太报文生效，从而提升TCP性能。 以TSO为例，内核封装出的TCP报文如下： |ETH_HEADER|IP_HEADER|UDP_HEADER|VXLAN_HEADER|INNER_ETH_HEADER|INNER_IP_HEADER|INNER_TCP_HEADER|INNER_TCP_DATA_NEED_TSO| 该报文的内部TCP数据需要进行TSO处理，即切成满足网卡MTU的报文，内核驱动将报文通过DMA送给网卡后（同时要提供一些元信息，如VXLAN头位置等），网卡负责将内部的TCP报文转换为多个内部TCP报文，封装相同的外层VXLAN头后进行转发，从而减少CPU的干预，大规模提升性能。 小结 个人认为VXLAN OFFLOAD这个名字不如用VXLAN-AWARE OPTIMIZATION比较直观，但厂商为了吸引眼球，自然是需要适当的包装，可以理解。 从实现的角度来说，万兆甚至更高性能的网卡本来就比较贵，这样的优化可能并不一定导致过高的复杂度，但在实现上却能够不依赖于OVERLAY交换机更实现性能的提升，应该是做为优化OVERLAY性能的首选方案。

拥抱开源如今成了一种潮流，既Juniper家的OpenContrail成为开源一揽子（之所以称为一揽子是用于区别现有OpenStack中由社区所维护的基于分散组件的松耦合方式）OpenStack网络虚拟化方案的首发明星后，Midukura这家公司也将自家的OpenStack网络虚拟化方案以开源方式来运作了，相比于OpenContrail的工程师的设备商研发背景，Midukura更具有IT运维背景（这点可以从其技术堆栈如scala编程语言、zookeeper/cassandra数据库、分布式架构推测出来，关于更细节的内容，后面我会陆续补充相关的分析），因此我个人还是更看好Midokura的方案，而从自己实际部署及验证的情况来看，Midokura要靠谱的多一点，当然这只是一家之言，也并非本文的重点，就不再展开。 在本文中我想谈的是，Midonet Tunnel Key的使用策略，与我们通常在基于OVS的方案中看到Tunnel Key（不论是NVGRE还是VXLAN）一般用做租户标识（即Virtual Network Identifier）不同，Midonet Tunnel Key则可以理解为按VIF分配的（实际上是基于Midonet的外部虚拟端口分配的，这里为了简化理解，可以简单认为就是按VIF分配的），而前者其实也是IETF相关标准文档所描述的用法。 Midonet之所以这样做的原因，与其架构实现有较大的关系，Midonet的架构总结起来，有如下的这几种特色： 全分布式架构，每个节点上运行一个Midolman进程（跑在JVM上），用于负责从分布式数据库（zookeeper）同步并发布虚拟网络配置信息，因此实现了去中心化，每个节点可以独立计算出转发结果 虚拟拓朴仿真机制，Midolman从VIF上收到报文后，通过拓朴转发仿真（与我们常规的Bridge->Router->Router->Bridge转发类似），就可以计算出目的VIF，从而得知目的虚拟机所在的主机，并在通过Underlay网络的IP以NVGRE/VXLAN的方式将报文Overlay传送给目的主机前就将报文编辑好 内核转发采用OVS datapath，即采用exact match的flow转发（megaflow暂不支持），以实现次包(即首包之后的包)的内核转发，提高转发性能 结合上面的介绍，Midonet采用基于VIF分配的原因就比较清楚的： 即然源端可以直接仿真出目的VIF且完成报文编辑，因此到对端唯一需要做的就是知道对端的VIF对应的OVS datapath接口是什么，NVGRE/VXLAN封装中的Tunnel Key则提供了一个简单方便的编码点，于是midonet就这么用了，另外一个Host上通过Zookeeper分配的Tunnel Key空间有10位数（非标准限制，而是Zookeeper的限制），对于一个cpu有限、memory有限的主机来说，10位数的VM已经远超能力极限的（咱们又不是天河一号，天河一号估计也不行），已经足足够用了 Midonet采用与OVS相似的机制，转件层面采用wildcard match流表，内核采用exact match流表，因此在主机上的Midolman扫描到VIF对应的TAP接口时，Midolman就可以为这个VIF生成一条匹配域为该VIF在该主机上所申请到的Tunnel Key为匹配项的wildcard match流表，其出接口即为该VIF所对应的OVS datapath接口，当收到含有该Tunnel Key的报文时，可以直接命中该wildcard match流表，提取报文字段生成exact match流表出接口继承该wildcard流表向OVS datapath下发即可，Wildcard match流表查询及exact match流表下发会非常迅速，也弥补了Java/Scala代码在未被JIT编译器优化时的性能损失，是一个非常优雅的方案 以上便是我个人对于Midonet Tunnel Key分配的理解，在软件定义网络这股风潮日近的今天，来自于互联网IT企业所带来的新思维，新用法，也许会继续改变设备商的开发模式，设备商要想办法适应并拥抱这种变化了。