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

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

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

SDN,也许你能想到这些:

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

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

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

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

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

1) SDN网络设备:网络设备(硬件网络设备或x86里面的软件网络设备,如vSR/vFW等)+SDN能力(可以是SDN芯片或开启SDN功能)

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

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

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

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

SDN抽象的模型

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

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

2) 混杂模式交换机:顾名思义,混杂模式交换机就是带有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通讯等问题。

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

整网拓扑如上图所示:

背景阐述:

① 所有交换机彼此互联

② 交换机通过带外方式(或网管网方式)连接Controller

③ 交换机均使用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)

④ 无特殊Controller指定,各类型都OK

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

工作流程介绍:

① 交换机连线至Controller,通过电信号,Controller发现有支持Openflow的SDN交换机接入,此时,Controller能够发现三台SDN交换机接入了。注意,此时三台设备之间的组网环境Controller是不清楚的。

② Controller通过packet-out报文,封装LLDP报文进Openflow,分别分发给每个交换机。此时的packet-out报文中含有动作:分发LLDP报文从交换机的每个端口发出去。

③ 此时交换机A根据Controller的动作指令,将LLDP报文从交换机所有接口发出去。交换机B和交换机C此时都能收到这个报文。

④ LLDP报文经过交换机之间的互联链路到达对端SDN交换机。而此时正因为交换机是SDN无脑交换机,他对于报文的处理都是上送Controller而非本地操作。则此时接受到LLDP的对端交换机会将LLDP报文再次封装,封装进packet-in,并上送至Controller。

⑤ 此时Controller收到对端SDN交换机封装的packet-in报文,报文里包含原本的LLDP报文。此时Controller就已经知道所有的拓扑连接关系了。

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

背景阐述:

① 网络拓扑已发现

② 控制器采用ODL(OpenDayLight)

③ 本地主机H1(10.0.0.1)和对端主机H2(10.0.0.2)均连接于SDN交换机下面

④ 整个过程是H1请求H2的ARP,H2响应H1

整个解析过程

① H1去pingH2,即10.0.0.1去ping10.0.0.2。因为没有H2的MAC,此时需要做一次ARP解析。此时ARP请求(原本是广播)被SwitchA通过Openflow形式单播上送给Controller(packet-in报文)

② Controller收到H1的ARP请求,记录H1位于Switch A下游,且记录相关的位置信息。

③ 正因为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)

④ 所有交换机都能收到此ARP单播请求,而只有Switch B会做出回应,因为H2接在Switch B下游。此时通过packet-in,所有SDN交换机会将此ARP泛洪发送到同网段的端口。

⑤ H2收到此时的ARP请求,正常做出回应。

⑥ Switch B收到H2的ARP响应,无脑上送到Controller。Controller收到ARP响应,发现正是前面发出的ARP请求的响应报文。记录此时的H2位置信息及ARP信息。

⑦ Controller通过Openflow将ARP响应回应给Switch A,Switch A将报文回送给H1。

此时做个小结,Controller已经完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯独H2此时只知道H1的IP,而不知道H1的MAC。

⑧ H1的整个ARP请求过程已经完成。接下来要输送ICMP请求报文。报文经由Switch A正常输送到H2(此时是实际转发流量,而且Switch A已有完整转发路径,不需要再上送Controller)

⑨ H2收到ICMP报文,想要回应,但是没有H1的MAC,需要再次做ARP请求。此时H2请求H1的MAC地址,报文被Switch B上送Controller,Controller已有H1的MAC,则Controller做出回应,将H1的MAC回应给H2。

⑩ H2收到ARP,则整个过程完整。回应ICMP报文。整个业务流打通。

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

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

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

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2015-06-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏农夫安全

如何移除Android应用广告

0x00 前言 我用以前做过的一个小游戏为例,源代码地址:http://git.oschina.net/androidsourcecode/parity,如果不...

49960
来自专栏杨建荣的学习笔记

服务器硬件问题整理的一点总结 (r7笔记第70天)

之前写过一篇通过shell来监控磁盘坏块的文章 http://blog.itpub.net/23718752/viewspace-1872978/ 从使用情况来...

41070
来自专栏开源优测

RFC2914 拥塞控制原理

15820
来自专栏睿哥杂货铺

SDN 技术指南(四):Open vSwitch

由之前发布的文章知道 Open vSwitch(Open Source Virtual Switch) 是一款基于软件实现的开源虚拟交换机。

30460
来自专栏张善友的专栏

在MongoDB中实现聚合函数

随着组织产生的数据爆炸性增长,从GB到TB,从TB到PB,传统的数据库已经无法通过垂直扩展来管理如此之大数据。传统方法存储和处理数据的成本将会随着数据量增长而显...

33170
来自专栏安富莱嵌入式技术分享

【RL-TCPnet网络教程】第2章 嵌入式网络协议栈基础知识

本章教程为大家介绍嵌入式网络协议栈基础知识,本章先让大家有一个全面的认识,后面章节中会为大家逐一讲解用到的协议。

14340
来自专栏SAP梦心的SAP分享

最新.net和Java调用SAP RFC中间件下载

      还记得2012年初我发布的全网络第一个关于.net 连接SAP RFC的NCO3原创博文,用的就是SAP出的最新的.Net Connector 3....

20000
来自专栏木宛城主

SharePoint 2013 Step by Step—— 为终端用户提供故障恢复的解决方案 Part I

Disaster Recovery,我把他直译"故障恢复",或者也可以翻译成 "灾难复原 "。光字面意思就可以领会到,当SharePoint Server发生了...

19770
来自专栏申龙斌的程序人生

访问Bigone API获取数字资产的余额

昨天写了一篇文章《Bigone API 升级到v2,害死程序员》,有人反映API文档无法打开,请自备梯子访问https://open.big.one。

14320
来自专栏前端黑板报

软件工程师需要了解的网络知识:从铜线到HTTP(二)—— 以太网与交换机

JohnLui:程序员,Swift Contributor,正在写《iOS 可视化编程与 Auto Layout》。 网络七层、四层模型 ? 四层模型是 TC...

37360

扫码关注云+社区

领取腾讯云代金券