SDN中“软件”如何定义“网络”

    SDN（Software Defined Network）软件定义网络，字面释义都说了是“软件”来定义“网络”，但有心之人会想：这个“软件”到底是如何定义了我们所熟知的“网络”？字字珠玑，今天就来扒一扒，这“软件”到底是如何定义这“网络”。

    众所周知，SDN软件定义网络，核心思想就是所谓的“转发、控制分离”，正所谓一谈SDN必谈“转发、控制”，一传十十传百，口口相传。当我们这些产品经理到客户现场交流SDN时，或许客户也能娓娓道来“转发、控制、分离”。但事实是怎么样呢，不妨我们以SDN为题做个头脑风暴，看看谈到SDN我们都想到了哪些关键词，并以此来总结出SDN几大特征库。

    SDN，也许你能想到这些：

    归结起来是这样几大特征：

    Controller控制器集中控制：集中式/分布式控制器无非是把原本网络设备从孤立的单点做了横向的扩张，将所有SDN化的网络设备统一被控制。这就好比将N台SDN小交换机“揉”成一台SDN大交换机，统一管理，统一配置。

    标准协议接口化：控制器与SDN设备之间的南向协议的标准化以及控制器北向API接口的标准化都是强调了SDN毕竟还是处理“网络”的工作，应用的事SDN“甭管”。可以类比到OSI七层模型，每层对应了每层的工作，彼此调用互不干涉。

    通用硬件：这里和NFV（Network Function Virtualization，网络功能虚拟化）没有关系。这里的SDN通用硬件指的是带有SDN处理芯片的网络设备或者是能实现SDN功能的网络设备。并非NFV所强调的x86取代ASIC的设备。

    正如下图所示，把SDN抽象出来看，其实包括了这样五个部分：

    SDN网络设备：网络设备（硬件网络设备或x86里面的软件网络设备，如vSR/vFW等）+SDN能力（可以是SDN芯片或开启SDN功能）

    SDN控制器：能处理SDN功能的控制器，可以是软件方式或软件嵌入硬件的方式。常见的有：floodlight、POX、NOX、OpenDaylight、Ryu、NSX等

    SDN APP：这更像是我们熟悉的网络上层功能，例如QOS、路由功能、Overlay功能等等。相比于传统网络，原本孤立的管理/配置如今被SDN统一化了，一个APP代表了整个SDN管理域内的所有此APP功能。好处就好比，网络出口要防DDOS攻击，调用了一个APP就能自动做黑洞引流操作；又好比，领导要开视频会议，调用一个QOS的APP就能全局做带宽质量保障；又例如，通过SDN负载均衡APP，可以实现根据不同业务/参数进行负载轮询。

    南向控制协议：这里场景的控制协议是Openflow，但绝非仅仅Openflow。可以实现控制功能的协议其实很多，除了最知名的Openflow以外，还有：Netconf、PCEP、LISP、MP-BGP、SNMP等等。

    北向API：此API的主要作用在于提供SDN控制器及其以下部分（南向控制协议、网络设备）能够作为网络驱动供上层应用调用。此上层应用可以是各种APP，同样也可以是Openstack、vCloud等云管理平台。

    SDN抽象的模型

    通常情况下，启用SDN的交换机可以分成两种模式：纯SDN交换机和混杂模式交换机。

    纯SDN交换机：交换机无脑工作，所有处理过程均依赖于Openflow或类似南向控制协议，主流的有：BGP/LISP/SNMP/NETCONF等。此时的交换机也叫做白盒交换机，其中交换机简化很多芯片功能，但增强了流表转发的功能，其中流表主要由ACL的TCAM芯片提供。只有这类TCAM能匹配SDN里面的十五元组，可以根据组特性进行转发。

    混杂模式交换机：顾名思义，混杂模式交换机就是带有OPENFLOW功能的传统交换机，可以根据需要将交换机的一部分转换成SDN，而其实质是传统交换机，有所有相关的转发、控制ASIC芯片。

    Openflow标准定义了控制器与交换机之间的交互协议，以及一组交换机操作。这个控制器—交换机协议运行在安全传输层协议(TLS)或无保护TCP连接之上。Openflow使用TCP端口6633或6653。

    每个流表中每个流条目包括三个部分：

    (1) 匹配match—使用ingress port，packet header以及前一个flow table传递过来的metadata；

    (2) 计数counter---对匹配成功的包进行计数；

    (3) 操作instruction—修改action set或者流水线处理

    交换机针对SDN有一个比较重要的消息类型：Packet-In，主要针对未知数据流无法命中流表的时候，作上送控制器的操作。

    同样，SDN控制器也有一个比较重要的消息类型：Packet-Out，主要针对下游SDN被管理设备，用于控制器指定从交换机的特定端口发送数据包，或者用于转发通过Packet-in消息接收到的数据包。Packet-Out报文中包含明确的Action动作。

    接下来，通过两个例子来展示“SDN新网络”如何利用“软件”解决传统网络中的问题。同样，可以帮助产品经理能够在跟客户交流SDN的过程中，更深入的阐述SDN的大致工作过程，以“软件定义”的角度来阐释传统网络中常见的拓扑发现、ARP通讯等问题。

    SDN Controller通过Openflow和LLDP发现整网拓扑

整网拓扑如上图所示

    背景阐述：

1. 所有交换机彼此互联
2. 交换机通过带外方式（或网管网方式）连接Controller
3. 交换机均使用Openflow协议。Openflow使用TCP端口6633或6653作为接收的监听端口。目前最新Openflow协议为1.5.1，详见ONF的spec。（https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/Openflow/Openflow-switch-v1.5.1.pdf）
4. 无特殊Controller指定，各类型都OK

    那对于传统交换机而已，正常情况他们是通过LLDP等类似的邻居发现协议发现彼此网络设备，形成整网拓扑。而在SDN环境中，设备是无脑的，此时需要借助Openflow和LLDP同时工作，来保障Controller环境下能够对全网进行拓扑发现。

    工作流程介绍：

1. 交换机连线至Controller，通过电信号，Controller发现有支持Openflow的SDN交换机接入，此时，Controller能够发现三台SDN交换机接入了。注意，此时三台设备之间的组网环境Controller是不清楚的。
2. Controller通过packet-out报文，封装LLDP报文进Openflow，分别分发给每个交换机。此时的packet-out报文中含有动作：分发LLDP报文从交换机的每个端口发出去。
3. 此时交换机A根据Controller的动作指令，将LLDP报文从交换机所有接口发出去。交换机B和交换机C此时都能收到这个报文。
4. LLDP报文经过交换机之间的互联链路到达对端SDN交换机。而此时正因为交换机是SDN无脑交换机，他对于报文的处理都是上送Controller而非本地操作。则此时接受到LLDP的对端交换机会将LLDP报文再次封装，封装进packet-in，并上送至Controller。
5. 此时Controller收到对端SDN交换机封装的packet-in报文，报文里包含原本的LLDP报文。此时Controller就已经知道所有的拓扑连接关系了。

    SDN控制器对于ARP报文的处理

    背景阐述：

    网络拓扑已发现

1. 控制器采用ODL（OpenDayLight）
2. 本地主机H1（10.0.0.1）和对端主机H2（10.0.0.2）均连接于SDN交换机下面
3. 整个过程是H1请求H2的ARP，H2响应H1

    整个解析过程

1. H1去pingH2，即10.0.0.1去ping10.0.0.2。因为没有H2的MAC，此时需要做一次ARP解析。此时ARP请求（原本是广播）被SwitchA通过Openflow形式单播上送给Controller（packet-in报文）
2. Controller收到H1的ARP请求，记录H1位于Switch A下游，且记录相关的位置信息。
3. 正因为Controller有所有交换机的拓扑及位置信息，此时Controller会给全网中每台SDN交换机都发送一个10.0.0.0/8网段的ARP请求消息，来请求10.0.0.2的MAC地址。但源IP并非10.0.0.1，而是Controller的网关地址，此处为10.0.0.254。此时报文均为packet-out，即通过Controller手工泛洪，但此泛洪是有选择性的，只针对同网段（10.0.0.0/8）
4. 所有交换机都能收到此ARP单播请求，而只有Switch B会做出回应，因为H2接在Switch B下游。此时通过packet-in，所有SDN交换机会将此ARP泛洪发送到同网段的端口。
5. H2收到此时的ARP请求，正常做出回应。
6. Switch B收到H2的ARP响应，无脑上送到Controller。Controller收到ARP响应，发现正是前面发出的ARP请求的响应报文。记录此时的H2位置信息及ARP信息。
7. Controller通过Openflow将ARP响应回应给Switch A，Switch A将报文回送给H1。
8. 此时做个小结，Controller已经完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯独H2此时只知道H1的IP，而不知道H1的MAC。
9. H1的整个ARP请求过程已经完成。接下来要输送ICMP请求报文。报文经由Switch A正常输送到H2（此时是实际转发流量，而且Switch A已有完整转发路径，不需要再上送Controller）
10. H2收到ICMP报文，想要回应，但是没有H1的MAC，需要再次做ARP请求。此时H2请求H1的MAC地址，报文被Switch B上送Controller，Controller已有H1的MAC，则Controller做出回应，将H1的MAC回应给H2。
11. H2收到ARP，则整个过程完整。回应ICMP报文。整个业务流打通。

    可以看到，最关键的应该是第三步，即Controller发送伪装ARP报文给全局同网段交换机，以此来实现ARP广播的同样效果。但也正是这样一个看似合理的安全行为，带来了很多不安全的隐患。可以想象，Controller有几种方式可以获取终端主机的MAC情况：1.通过免费ARP的方式、2.定时申请下游终端的MAC方式，都可以保证对下游终端MAC的始终更新。

    但同样，集中Controller的方式也带来了单点安全的风险考虑，一旦一台下游主机中毒，不断变化自己的MAC不断做出更新动作，此时会极大消耗Controller的资源，形成DOS攻击。同样，Controller的安全如果不是很坚固，则一旦被攻破，所有终端信息一览无余。

    抛砖引玉，SDN的安全还有很多路要走。

    作者：王彬   来源：厂商供稿

相关阅读 华为携手比利时电信完成业界首个1T OTN现网测试 运营商的大数据应如何“变现”？ 华为联合南非MTN完成业界首个FTTH内置OTDR规模商用 边建边拆！基站建设难题如何破解？ PMC推出DIGI-G4 瞄准城域网络400G OTN交换 HTC回天乏术：它如何一步步从辉煌走向没落 索尼移动将再裁员千人 经营困难或因放弃OLED 天翼云4.0快•乐分享发布会 精彩不断 中国如何像韩国一样网速全球第一？不垄断？ 一加发布氢OS：拒绝类iOS 即将开始内测招募

1、回复“LTBPS”免费领取《《中国联通5G终端白皮书》》

2、回复“ZGDX”免费领取《中国电信5GNTN技术白皮书》

3、回复“TXSB”免费领取《通信设备安装工程施工工艺图解》

4、回复“YDSL”免费领取《中国移动算力并网白皮书》

5、回复“5GX3”免费领取《R1623501-g605G的系统架构1》

7、回复“6G31”免费领取《基于云网融合的6G关键技术白皮书》

8、回复“IM6G”免费领取《6G典型场景和关键能力白皮书》