linda

主要分享如下几个主题：
1. SDN现状和对SDN的一些误解
2. SDN交换机的实现技术流派
3. SDN的一些应用场景
最后是Q&A环节

一．SDN现状和一些误解
我今天主要分享一下我目前看到的SDN最新动态，一些技术流派，一些SDN应用，特别是在云计算里面的应用。
SDN在13，14这两年被炒得非常火，到了今年，感觉声音边小一些了，所以很多人在问，是不是SDN不行了？
我的看法不是这样的，我认为按照Gartner的技术成熟度曲线，现在SDN走到了谷底之后，开始向上。

但是现在业界对SDN仍然存在很多误解，我这里得把它澄清一下

最常见的一个，尽管一再有人来澄清，但是还是会被误解，就是总是把openflow等同于sdn，一说到sdn，就以为是openflow的实现。如果非要说openflow=sdn，那只能说这就是狭义的sdn。广义的sdn则是控制跟转发分离，有开放的API和集中的控制器。这是广为接受的定义

第二个误解，总是有人觉得如果用了sdn，就是一个或者几个控制器在那里控制一切，所以常常会质疑，这样sdn网络如何scale?如果真的sdn是这样的话，那确实没有可扩展性。但是实际上，SDN并不是要让控制器去控制一切，而只是让用户可以通过控制器去控制他想控制的东西，对于对那些业务无价值的东西，完全没必要去控制，而可以仍然靠传统协议去做。
举了个例子，在数据中心出口，相对公网IP的出入两个方向进行限流，向下的方向，可以有很多个端口，用户使用SDN想得到的价值，只是限流，至于限流之后，报文如何转发，其实他并不像去控制，这个时候，怎么办？让传统的mac学习去做。
再比如，在网络虚拟化的应用里面，对用户最有价值的部分，需要sdn去控制的部分在哪里？在边缘，边缘承担着识别VM，识别租户，创建虚拟网络的重任，而核心汇聚呢？只是一个报文转发而已，那这种情况下，你为什么要用SDN去控制核心汇聚呢？没必要。
这是第二点。

然后相关的第三点误解，跟第二点有关系。就是认为SDN交换机，必须是交换机上没有任何控制协议，所有的控制都在控制器上，但实际上，要看场景，很多场景，在交换机上仍然可以有控制协议，只是它需要提供出接口来，让用户去控制想控制的东西。
用一个类比来说明，人体有植物神经和动物神经，前者比如呼吸，心跳，后者比如举手投足，如果前者也要靠大脑来控制，那肯定来不及。SDN也是同样道理

第四点，有人认为OpenFlow交换机需要任意灵活才行。但是实际上，既无必要，也不可能。openflow交换机的灵活性，其实是体现在它可以满足各种不同场景的需求，但是在任何一个特定场景下，其实不需要任意灵活，某个特定场景，总是有固定的模式，比如匹配特定的字段，做特定的动作。
基于这样的一个事实，其实可以通过组合现有的转发表项，来支持不同的openflow场景。并非说一定要SDN芯片才行。当然，如果芯片能够对SDN支持得好，那可以支持更多的场景，有更小的限制。

第五点，现在一提到云计算网络虚拟化，说用到了SDN，马上就有人会问能跟不同SDN交换机互通吗？或者能跟Ryu, ODL, FL, ONoS等控制器对接吗？答案是一般情况都不能。因为对于SDN来说，它一定意味着基于场景的定制，不可能随便拿一个控制器，随便拿一个SDN交换机，就能支持一个SDN应用，特别是网络虚拟化这种复杂应用，一定是要特定的控制器，或者基于商业控制器做很多定制，还要对SDN交换机做一些定制。那种随便拿一个控制器和交换机就可以直接用的想法是理想化，不现实的。
我这里说的都是硬件SDN交换机，不包括纯软件的，如OVS。

二．SDN交换机的各种实现流派
其实误解还有很多，我就不去一一列举了，接下来再说说SDN交换机的各种流牌。
第一种实现，就是纯openflow的实现。 不支持任何传统协议。像我们的V330/V350/V580，目前就是这样。很多厂商都宣称实现了openflow1.3，但是实际上能力差异很大，这主要不是设备商的能力差异，而是芯片的差异。但是很多人不知道，以为买了个宣称of1.3的交换机，就真的都能支持所有能力了。实际上能支持到50%就差不多了。比如我们在一个客户那里竞标，客户的一个要求很简单，就是要求匹配IP后能修改IP，这是openflow1.0就要求的。我们的设备报价很高，对手的客户关心很硬，但是最后这个标被我们拿到了，为什么？就是因为我们能支持修改IP，对方不能。为什么会这样？因为我们用了盛科自己的能很好支持SDN的芯片，对方用了商业通用芯片。而这个需求是客户刚需，没得商量。

第二种实现，是hybrid，所谓的混合模式，就是交换机转发面先进行openflow的pipeline处理，如果openflow对这个报文不感兴趣或者没有直接丢弃也没直接转发掉，就继续走后面的普通二三层处理。比如我在前面举得那个例子，先使用openflow进行限流的处理，处理完之后走普通二层mac转发，学习。应该说这是第一种的超集，OVS就支持这种处理。我们很快也会支持。

第三种实现，则是完全跟openflow没关系，交换机内部仍然是传统交换机，有各种传统二三层协议。但是比传统交换机多了一点，它能够提供出open API来，这里的Open API有很多种，而且大多数都是私有的，比如rest API, JSON RPC API, netconf, XMPP。比如juniper的contrail，就用XMPP, CISCO的ACI，是用它自己私有的一个协议oplex。Arista用JSON RPC。我们也支持JSON RPC，我们给客户做得云方案中，有一套方案就是用了JSON RPC。 这种方案有一个很大的好处，就是不需要考虑跟传统网络交互的问题，而又可以通过API控制。只是它不是标准的，这一点有人不喜欢，但是更多客户无所谓，能解决问题就行。
基本上总结下来，就这三种，其他万变不离其宗

三. SDN在云计算之外的一些应用场景
接下来我说一下SDN目前的一些主流应用场景

先说一个相对简单一些，但是现在很多大公司都在做的，就是在广域网的应用。


大家所熟知的一个就是Google的B4网络，用SDN来做流量调度，带宽优化，提高利用率。这是比较复杂的，现在很多运营商都在搞。
还有简单一些的，比如一些IDC在全国有很多机房，一些客户租用了他们多个机房，需要连在一起，二层互通。还要能限制带宽。现在就有IDC要用SDN来做这事，有的已经做了（比如我们一个客户澳洲电信）。用户可以自助服务，自助申请互联，自助调整带宽。光跟我提过这个需求，让我们帮他们做的IDC就有5家，现在电信要建立除了移动和固网之外的第三张网，就是DCI网络。

还有一些小的应用，比如基于SDN的方案，来做扛D攻击，入侵检测服务器检测到攻击之后，通过控制器给SDN交换机下发流表，同时控制边界路由器，将流引到SDN交换机，进行流量清洗，这是我们日本一个客户的做法。 国内还有一个一线的IDC客户，玩法则另有不同，说起来比较复杂，有兴趣的后面可以细聊。这里我就不多说了。

还有一些边边角角的奇怪的应用，比如我们一个客户，因为视频接收设备接在网络里面，收到一些报文的干扰，导致有马赛克。他们又查不出原因在哪里，索性就在链路上，串一个SDN交换机，这个交换机把需要的视频节目放过，其他报文全部丢弃，然后问题就解决了。
四. SDN在云计算里面的应用场景
前面把一些次要的场景都讲完了，最后我就专门来讲一下，SDN在云计算里面的应用。这是重头戏，也是目前SDN应用最广泛的领域。

说到SDN在云计算网络虚拟化里面的应用，也有误解。一说到SDN，有人马上就想到SDN交换机，但是其实，目前的各种网络虚拟化方案，有很多是用纯软件的方案来做的。

典型代表：OpenStack neutron原生态方案，Vmware的NSX， MidoKura公司的MidoNet，Nuage公司的方案等等。

他们用的都是纯软件，网络虚拟化的所有动作都发生在服务器，国内的比如青云，也是如此。 而且，并非这些方案都是用到了OpenFlow，基本上没有用纯OpenFlow的，就算用了OpenFlow，也都是结合了传统的东西。
有的方案压根跟openflow无关，比如Nuage，Juniper Contrail。当然neutron原生方案，L2部分确实用到了openflow，而且是很复杂的多级流表。华为的drangonflow也是，而且华为的dragonflow是L2/L3都用openflow，不像neutron，是个混杂品。

这里还有一个说法需要矫正，就是有人把openflow跟overlay对立或者并列，其实这个不对。overlay只是一种组网方案，openflow是一个控制协议，所以实际网络中，可以是这样的：控制器通过openflow协议控制vSwitch来构建一个overlay网络。

纯软件方案大家实现各异，细节没办法在这里讲，这个得另外写文章。我后面再讲一下，硬件SDN在网络虚拟化中可以起到什么作用。

硬件SDN实现网络虚拟化的典型代表是Cisco。
它的ACI就是这样一个方案，其他一些设备商或多或少也都有一些自己的方案。但是也有设备商只推软件方案的。

当然，我们公司也有自己的基于硬件SDN的一套方案，目前已经在多家客户那里部署或者POC了。 很多人都知道UCloud用了我们很多SDN设备，这个涉及到客户机密我不好多说，只能说一点，UCLoud有它自己的用法，而且实际上，我们已经正式部署的那些客户，每家都有不同，都体现了云计算对SDN的一些需求，我后面一个一个列举一下。

使用硬件SDN交换机做网络虚拟化，大概的思路就是，把tunnel overlay的工作，做到TOR交换机上，交换机上可以来识别VM，识别组网，push/pop tunnel header，如果再进一步，还可以做一些限流，security group（静态，无状态的）。如果做得更好一些，可以把分布式L2/L3都做在硬件SDN TOR。每个TOR都是它所挂的VM的L3 GW。这就是所谓的分布式路由。

但是硬件SDN来做这个网络虚拟化，有不少限制，第一个，流表数量没有软件那么大，当然，我们计算过，应该够用。 第二个，有些工作做不了，比如NAT/LB/FW/VPN等等，这些仍然需要专门的南北向Internet GW，只不过SDN TOR仍然可以帮这些GW来offload tunnel。这样有些硬件防火墙不支持tunnel的话，可以跟SDN交换机一起工作。
这是一个概览。下面我就分别说一下几个需求点，或者说场景。

硬件SDN做网络虚拟化的第一个需求点，是希望通过SDN交换机来offload一些工作，提升性能。我们自己做过对比测试，确实比原生态neutron提升很大，而且很重要的一点是，性能恒定。不像我们测试纯软件方案的时候，每次测出来的结果都不同，挺郁闷。它能提升性能的原因主要有着几个 1）把tunnel工作放到交换机，网卡的TOE模块就仍然可以发挥作用，做TCP分片加速 2），tunnel操作本身也消耗CPU 3）如果能把一些复杂流标操作也放到TOR，那就更好了。
当然现在也开始有一些网卡可以做vxlan，具体效果如何我没试过，不知道。

第二个场景，用SDN交换机来做P+V
所谓的P+V就是物理裸机接入到虚拟网络，因为在纯软件方案中，vxlan可以终结在vswitch，但是对于物理机，没有vswitch，所以最好的方案其实就是把vxlan终结在SDN TOR，SDN TOR作为tunnel gateway。这种方案包括vmware都支持，支持跟一些硬件SDN TOR对接，所以可以认为是一个刚需。

我们有四五家客户都是因为场景1和2找我们的。

第三个场景，使用SDN来支持service chain引流，特别是跟云安全结合。
在传统网络里面，要做安全，很好做，安全方案跟网络是松耦合，只需要在出口设备旁挂或者串接FW就可以了。但是到了云里面，一切都变了。
我至少聊过国内20家以上做云安全的，大家都跟我讲了同一个需求，如何在云里面，把东西向流量引导vFW, vWaf,或者硬件FW上去。
为什么这个这么难做？因为在云里面，一方面，VM都是动态的，但是它应该应用的安全策略确实固定的，那么你如何做到策略跟随？策略跟随是思科ACI一直强调的一个卖点。第二个原因，现在很多云使用tunnel overlay，VM的原始报文，在服务器内部就封装到tunnel里面去了，对物理网络不可见，这种情况对引流就造成了更大的困扰。刚刚一个小时之前，国内一个做安全的兄弟还在问我这个问题，说如果解决了这个问题，他们可以去影响政务云标准。

如果使用SDN TOR来做tunnel overlay，那么这个问题就会容易多了，因为SDN TOR可以来识别VM，识别报文，可以接受来自控制器的安全策略，可以在SDN TOR和安全设备之间建立起tunnel连接，把流引过去。

当然，这个从原理上来看，是没问题，但是实际操作的时候，实现还是会比较复杂。但是我们看看思科ACI的宣传点就知道，这肯定是一个很好的路子，关键在于你能把它做得足够好用。

然后接着讲第四个场景。
第四个场景也很奇葩，我们有三家客户（据合作伙伴说其实还有别的客户也有需求），是因为这个原因找我们的。

这里面，有两个客户，要解决的问题是，他们自己或者他们的客户有很多VMware的传统产品（不支持NSX），他们现在又引入了KVM, XEN，要跟VMware混合组网，而且要使用vxlan。但是NSX太贵，不想买NSX。那怎么办？业界对此也有方案，有人是在VMware 计算节点里面起一个VM，在这个VM里面实现了一个vswitch的功能，所有同服务器内的其他VM要往外发包，就先到这个VM里面绕一圈，比如我看HP的helion就有这样的做法。但是这种做法的问题显而易见，性能太差。
还有一个客户，则是因为他们用了Power服务器，而且还有AIX，里面的vSwitch更是简单的要命。也是想支持tunnel overlay。
无论是前者还是后者，要解决的问题是一样的。所以我们给出的方案就是使用SDN TOR，在vswitch里面只是做基本的vlan，这个不用NSX就能支持，power自己也能支持。但是报文送出来之后，SDN TOR上把vlan转换成vxlan VNI。这样就可以很好的解决这个问题。我们有一个国内给广电领域提供服务的客户，就用这个方案给各个电视台做。电视台用了大量Vmware。

基本上云计算的场景，主要就是这些。如果非要再加一个的话，那是一个小场景。 一些IDC，客户买了多个公网IP，然后是每个IP给一个带宽，比如10个公网IP，每个给10M带宽，坏处是彼此之间不能共享，然后需求就是在出口处，放一个SDN交换机，把这些公网IP捆绑起来共享带宽，用户就很happy了，而且不能是手动来做，是要跟云平台联动。

五. 问答环节
Q：是否觉得云方面或是虚拟化方面的sdn的需求比来自其他的越来越多？
A：对，需求特别多。特别是很多做云的公司，没有网络人才，对网络比较恐惧，所以更容易有需求。这里面有些其实是伪需求，只是因为不懂，而有些是真的

Q：盛科的service chain方案，如何标记流的？
A：这个一般是根据五元组
Q：重叠地址五元组可能会失效吧？
A：VNI+五元组

Q：感谢大神的精彩分享，关于DCI，如果木有mpls骨干网，怎么解决？
A：现在也有用GRE或者VxLAN的，我觉得没必要非用mpls

Q：不是需要组播支持吗？
A：既然说到这个问题，我就再多讲一点，这里存在另外一个误解
很多人都认为vxlan跟nvgre的区别是vxlan需要组播，这完全是无稽之谈。两者都可以不需要组播。两者的区别只是在于第一，封装格式不同，前者是UDP，后者GRE，第二用来做负载均衡的方式不同，前者把hash值放在UDP source port里面，后者把hash指放在GRE KEy里面，除此之外就没区别了。哦，不对，还有区别，前者是思科，arista等推的，后者是微软，阵营不同：)

Q：听人讲华三的说可以不用NSX直接vmware接Sdn tor支持 vxlan，盛科有这个方案？是否可行
A：见我上面第四个场景

Q：你们都产品有用来解决裸机和虚拟网络打通的商用案例么？
A：见我上面第二个场景。

Q：有集成的管理方案吗？我碰上这个case了，管理方案太复杂了，好几层
A：这个是我们客户自己做得管理平台，如果需要，我可以帮忙问问他们卖不卖


Q：前面提到某用户希望用盛科SDN交换机修改IP地址，能介绍下需求吗？是要做NAT？thx
A：这里有很多个场景，日本那个客户，是做完流量清洗之后，把目的IP改掉，原路返回去，避免对端再把它送回来，然后在内网络里面这个被修改过的IP可路由，这样避免使用tunnel。
还有是做简单的负载均衡，类似LVS，只是不需要有状态，不需要到7层
还有一个则是广电把外部的节目源统一编址。

Q：能介绍一下sdn交换机的硬件架构么，是ASIC还是NPU
A：对于交换机来说ASIC是主流。华为有NPU，但是这个只能作为补充，不能作为主力。成本，功耗，吞吐量都是问题
Q：为什么不用NPU去做？ASIC不够灵活
A：成本太高，研发成本也很高，如果市场足够大，需求足够刚性，那说不定也会有人做，呵呵。否则都是吸引眼球宣传宣传。


Q：盛科交换机是不是已经有出方向openflow流表支持？
A：这个是可以做的

Q：问下抗D场景，用的SDN交换机是纯openflow的还是hybrid？检测到攻击模式=》切换OF下流表drop……
A：对，用流表来做清洗。 关于这个案例，我们那个日本客户写了三篇非常详细的帖子，发在网上，把来龙去脉前因后果都写了，你们可以去看看。连测试步骤都写得很清楚。http://packetpushers.net/centec-v330-my-kind-of-openflow-switch/
我们国内还有一个大的IDC，用法跟这个日本的不同，但是目前我还不能透露。

Q：检测DDOS用什么？In-Mon？
A：检测跟我们无关，我也不知道他们怎么做的。



Q：刚才介绍的分布式路由，有案例介绍下吗
A：有的啊，都部署了几个了。理论上就是把DVR那一套做到SDN交换机。

Q：说到的国内服务商DCI互联自服服务，自助调整带宽等是直接你们平台上（cloud manager），还是跟用户OSS API？
A：DCI这个跟云没关系，是目前他们是给客户提供了web界面，用户可以自己去操作，你们可以去看看pacnet的服务，如果使他们用户的话。

Q：dvr做在tor sw上，物理tor sw的冗余是如何解决的？
A：这是个好问题，现在是使用mlag，确实这里处理起来比较复杂，需要复制

Q：Pacnet的案例，很好奇你们怎么跟Vello集成
A：Vello的平台，集成了我们的交换机和另外一个公司的光传输设备，给客户提供整体方案。我们帮他们做了不少定制。
国内现在缺少像vello这样独立的第三方SDN应用和服务提供商。魏总的未来网络准备朝这方面努力


原文：http://blog.sina.com.cn/s/blog_70243ac60102w4l3.html

[ 本帖最后由 linda 于 2016-1-6 17:06 编辑 ]