盛科从2011年开始涉足SDN，从2011到2019这八年中，我基本上全程参与这个过程。从刚开始的产品设计阶段，到后面的产品化，再到现在与客户打交道卖SDN产品。可以说从研发到市场销售，一路走来，有很多感悟，最大的感悟就是我今天想跟大家聊的——理想与现实之间的差距，到底有多大？

首先我们聊一聊什么是理想？在很多技术论坛和文章上面，大家能够看到的很多高大上的技术，SDN、SD-WAN、P4可编程还有IBN，这些高大上的技术都是很理想化的东西。单纯从技术层面来说，肯定有很多闪光点。但实际上只有一部分技术成功了，那么为什么有些技术没成功，或者说它的成功并不符合大家的预期？那是因为在考虑这些技术的时候，有很多现实的因素没有考虑到，真正落地的时候，才会发现与想象中的差距还很大。

那么什么是现实呢？例如我向客户推销SDN的时候，客户问：你这个东西能帮我赚钱还是省钱？如果我没有办法回答这个问题，那客户就根本不再听我说那些吹得天花乱坠的概念，例如解耦、自动化之类的。

所有的技术真正落地的时候，都会碰到这样现实的问题——怎样跨越理想到现实鸿沟，这就是我今天想跟大家来聊一聊的内容，我们到底是怎么样怀揣理想而面对现实的。

因为我一直在一线奋战，跟太多太多用户打过交道，被问了太多太多的问题。下面我带大家盘点下，这些年，SDN受过的那些委屈。

一、这些年，SDN受过的那些委屈

1、明明是个短跑运动员，非要说俺是个十项全能
为什么现在很多人认为SDN不行了，就是因为大家一直对它的期望值不对，你一直以为它啥都能。SDN刚开始炒的时候，大家都很兴奋，跟打了鸡血一样，连研究与做设备的都很兴奋，觉得SDN好像是个救世主，能够把所有的问题都解决了。但就是因为你的期望太高，才导致失望太大。它并不是说什么事情都适合去干，有的事情它干起来很费力的，还不如传统交换机来做，有的事情它干起来是很费钱的，明明一万块钱能搞定的事情，要搞十万块钱。在有些场景里面，它的规模根本做不大，用传统交换机可能更适合。所以大家对它的期望值就不对。

2、明明我有N条路，却总认为只有一条唯一正确
SDN是一个很宽泛的概念，不要一提到SDN就想到OpenFlow，SDN有很多技术实现，并不仅仅是OpenFlow，不能因为OpenFlow有很多限制，就要认为SDN不行！

3、明明我的特色是基于场景定制，却偏希望我提供标准化服务

• 不谈场景的SDN都是耍流氓
• 没有普适性的广义SDN控制器，只有基于场景的广义SDN控制器

4、明明我只想控制我感兴趣的，非要让我控制所有

• 同一台设备上，SDN部分跟传统部分可以有机融合

• 同一个网络里面，SDN交换机可以跟传统交换机有机融合

5、明明是想解耦，却偏偏要求绑定

• SDN控制器和交换机可以解耦，但是甲方却还是希望一个厂商把控制器和交换机都提供了

• 所以现实结果是：SDN使客户绑定的更深而不是更浅了。

6、明明你需要的只是星星，却要求整个宇宙

• OpenFlow交换机是ASIC实现的，你却要求它像软件实现的OVS一样灵活，一样大容量
• 你的应用只需要一级流表，只需要能匹配五元组，你却要求10级流表，能够任意匹配12元组

二、SDN，运用之妙存乎一心。

正是因为大家对SDN有着如此多的误解，导致了很多时候项目落地时，就会出现各种各样的问题，这些问题有些时候并不是技术本身造成的，而是一开始你的期望值就不对，那么怎么样来纠正自己的期望值？在我看来，SDN不是具体的技术，只是一种理念，你要用好这个理念有很多种方式。

1、SDN可以用纯OpenFlow

• 彻底的控制跟转发分离
• 交换机用pure openflow
• 如点对点的DCI专线服务

特征：
1.完全基于策略转发
2.表项规模可控

2、SDN也可以用私有API

• 跟OpenFlow完全无关
• 协议全部留在交换机
• 通过开放API，将部分控制策略放到控制器
• 如基于SDN交换机的云计算网络虚拟化

特征：
1. 配置需要动态下发
2. 无需灵活流量调度
3. 转发表项动态学习

3、SDN还可以用混合模式

• Pure OpenFlow或者私有API都不是万能的
• 用混合模式，控制你想控制的东西
• 如点对多点专线

特征：
1.需要灵活策略控制
2.部分转发需要可控，部分需要自动学习

4、SDN可以用纯软件方案
这些都是纯软件方案，控制器控制的都是虚拟网元

特征：
1.需要网元足够灵活
2.想完全跟硬件解耦

5、SDN可以不用集中控制器

• 用OpenFlow交换机取代LVS/F5/A10等四层负载均衡
• 控制器内置于OpenFlow交换机内部CPU

特征：
1.只控制单台设备
2.需要控制器跟交换机频繁交互

6、SDN设备可以全网部署
如基于SDN的DCI骨干网
7、SDN设备可以只部署在接入
如某些厂商的云计算网络虚拟化方案
8、SDN设备可以只部署在核心
核心位置放OpenFlow做Service Chain引流
9、SDN可以不用专门的SDN芯片

• 当前市场上的OpenFlow交换机，绝大多数用的是传统交换芯片的TCAM表项
• 一小部分，在传统交换芯片上做了微创新
• 还有一小部分，用了NP或者FPGA

10、SDN甚至都可以不用TCAM做流表
充分利用现有ASIC各种表项，基于线性查找/hash查找/LPM算法查找

• 把表项做大
• 支持多级流表

适用于固定字段的匹配场景

• 如云计算根据mac + vlan进行VM转发
• 如负载均衡场景，根据IPSa + TCP Port进行会话识别

前面所讲述的内容还是偏向于技术分析，最好这一部分我们来讲一讲，这些年我们实现的，SDN成功落地的场景。我认为真正对SDN能够有所帮助的，也正是这些场景。

我认为，当有人说SDN已死的时候，有人正在靠SDN赚钱，只是，你看不到或者不理解而已！

三、其实，SDN干这些事干得挺好

1、有这些特征的场景，可以考虑SDN
SDN的两大核心驱动力

• 业务自动化

配置、策略需要频繁变更
网络设备需要通过控制器跟业务系统联动

• 转发面灵活性

报文转发模式不同于传统固定模式
可以用，也可以不用控制器参与，主要强调转发面的灵活

2、基于SDN的DCI

比如一些做传输的、VPN线路的、数据中心的公司，它们在全球拥有非常多的节点，但是客户要求开设一条专线，利用传统交换机实现就比较复杂，这时候SDN的优势就显现出来。

3、基于SDN的服务链

它是一个纯openflow的实现。例如外网和内网中间串联了很多安全设备，如果其中有任何一个设备需要升级或者发生故障的时候，公司的网络业务都会受到影响。现在串了一台SDN交换机进去，然后把完全设备旁落在它上面。这样通过控制器对SDN交换机下流标，只需要改变控制器策略，就可以轻易切换。

4、基于SDN的IDC出口流量调度

这是一个典型的省钱案例。我们知道，IDC出口流量往往会涉及到多家运营商的介入，举个例子，有些IDC厂商一共需要10个外向端口，其中5个跟运营商买断，另外5个按流量计费，很显然，IDC更为倾向的做法是先将流量牵引到5个买断的端口，剩余的再按流量计费，然而这种做法需要耗费大量的人力物力，实施性不高，且人为配置也很容易出错，基于SDN的IDC出口流量调度能够实现自动化引流，节省大量的费用。

另一方面，有一些大的IDC机房往往会有很多种出口，这通常又会牵扯到运营商的切换问题，基于SDN的IDC出口流量能够实现全网调度，例如，从电信迁移到联通等等，同时，SDN还能够实时监测到线路的状况，以便及时作出响应。

5、基于SDN的网络虚拟化或者裸机云网络

• - 基于SDN的网络虚拟化也是基于EVPN+API,我们有自己的合作伙伴，控制云跟云平台联动。
• - 基于SDN的裸机云网络，全部都是物理服务器，没有虚拟化。

6、基于SDN的电视台播控交换矩阵

我们的合作伙伴可以用SDN交换机给电视台做播控的交换矩阵。它也是一个纯Openflow的实现，当然这中间还设计一些别的技术，例如地址转换。

7、基于SDN的校园网改造

这个方式实际落地的时候，院校全部都采用Openflow加上传统的混合模式交换机。

8、基于SDN的智能拓扑连接器

这个方式特别适合在实验室进行实现。利用控制器下策略，把内部打通，达到左边图形的效果。

最后用一句话作为总结，“SDN is dead，Long Live SDN!”，中文的意思是“SDN已死，SDN永生”。这是国外一个叫做SDNcentral的网站创始人，在一个论坛上说的，他说：“什么时候SDN就成功了呢？就是当大家都不再谈论它的时候，但事实上它已经默默地支撑起了底层网络的运行，大家不再察觉到它的存在，然而它却真实存在，这个时候它就获得了成功。”

本文作者：张卫峰，转载自https://www.sdnlab.com/23681.html