SDN原理 OpenFlow协议 -4
通道 Channel
在前面的OpenFlow的内容中,我们提到了在交换层所采用的流表是控制层的Controller下发的,那么Controller是如何下发流表的呢?中间经过了哪些的流程和步骤?控制器和交换机的会话是如何建立的?
这就是我们今天要介绍的内容,Channel。
连接建立
Hello包会定期的交换,其中最核心的就是OpenFlow的版本号。
Hello1:Switch -> Controller 你支持版本1.3吗?
Hello2:Controller -> Switch 我支持啊
就像之前的OSPF的Hello报文要交换RID等等的信息一样,比较好理解。
Feature request:Controller -> Switch 你的OF支持哪一些特性?你的接口信息是什么?也就是询问交换机所能提供的功能。
Feature reply:Switch -> Controller 交换机回复一个非常大的包,把它的所有配置信息,所有接口信息都回复给Controller。
Set config:Controller -> Switch Controller下发命令,根据交换机提供的信息对交换机进行简单的设置。
至此,Controller和交换机建立起了一个联系。
packet in:Switch -> Controller 当交换机本地没有匹配到与流相符合的表项 或者说 没有FlowTable(默认)的时候,会将数据包丢给Controller。
packet out:Controller -> Switch Controller回复指示信息,给Switch处理该数据包提供了方法,或者说选择的路径。
port status:Switch -> Controller 当交换机的端口状态发生变化的时候,交换机通知Controller,告诉Controller这个变化,让Controller刷新路径信息。
消息列表
三类消息:
- Controller-to-Switch 消息:有控制器发起,用来管理或者获取Switch状态。例子:上面的 Feature Request 和 packet out。
- asynchronous 消息:由 Switch 发起,用来将网络事件或者交换机状态变化更新到控制器。例子:上面的 port status。
- symmetric 消息:有 Switch 或者 Controller 发起。
第一类消息顾名思义,是由控制器下发到交换机的,比如下发流表。
而第二类消息可以理解为由 交换机向控制器 发送的消息类型,比如端口状态辨认等等。asynchronous直译是 “异步的”。
第三类消息,这类消息是控制器和交换机的 交互,也就是说,既有控制器发送给交换机的消息,也有交换机发送给控制器的消息。symmetric 也就是 “同步的”。典型的第三类消息是Hello报文,你Hello来我Hello过去。
1、Controller‐to‐Switch
控制器至交换机消息此类消息由控制器主动发出
Features 用来获取交换机特性
Configuration 用来配置Openflow交换机
Modify‐State 用来修改交换机状态(修改流表)
Read‐Stats 用来读取交换机状态
Send‐Packet 用来发送数据包
Barrier 阻塞消息
2、Asynchronous
异步消息此类消息由交换机主动发出
Packet‐in 用来告知控制器交换机接收到数据包
Flow‐Removed 用来告知控制器交换机流表被删除
Port‐Status 用来告知控制器交换机端口状态更新
Error 用来告知控制器交换机发生错误
3、Symmetric
对称消息,可以由控制器或交换机主动发起
Hello 用来建立Openflow连接
Echo 用来确认交换机与控制器之间的连接状态
Vendor 厂商自定义消息
更进一步的细节,可以参考:OpenFlow消息
协议交互
我们选用的模拟器,首选Mininet,仅使用一条命令 sudo mn 直接就创建了一台控制器,一台交换机,两台电脑的网络拓扑。
甚至,我们可以用Mininet的一条指令,创建一个数据中心!It‘s amazing!
视频教程介绍了传统网络协议和OpenFlow交互的一个案例。
使用 sudo mn 建立一个 含有一个Controller,一个Switch,两个PC的简单网络拓扑。
简单的介绍一下名称:两台PC,h1和h2;连接在h1上的接口eth0;连接在h2上的接口eth0;Switch,S1;在S1上和h1连接的接口eth1;在S1上和h2连接的接口eth2;Controller,简称C;在S1上和C连接的接口L0.
h1想向h2发送一个数据报文,但是不知道MAC地址;传统网络的解决方法是ARP泛洪获知MAC地址,那么在SDN是如何实现的呢?
(1)h1通过ARP协议,向所有接口泛洪ARP请求:报文通过eth1接口来到了S1。
(2)S1不知道这个报文要发到哪里去,并没有合适的表项让它匹配;于是乎,将请求报文转给了控制器:Packet-in消息。
(3)控制器也不知道这个报文要到哪里去(可能是因为刚刚建立连接,还没有建立一个合适的网络拓扑),于是向交换机S1下发指令,向所有接口(除了eth1)泛洪该数据报:Packet-out消息。
(4)S1向eth2接口发送该ARP请求报文,来到了h2.
(5)👌,h2是目的地,它想向目标MAC地址为h1的MAC地址返回一个ARP回复,但是它也不知道h1在哪里,于是也向eth0-eth2这条链路泛洪了这个ARP回复。来到了S1。
(6)由于没有匹配的表项,S1把它交给了控制器:Packet-in。
(7)控制器这个时候大致知道了网络拓扑的结构,根据这个网络拓扑结构,计算最优路径;决定向S1下发流表更新流表项:Modify‐State。
(8)S1拿到了这个更新消息,向h1转发这个ARP回复,h1就得到了目的的MAC地址,可以开始愉快的通信了~
传统网络的做法,中间的交换机是有“学习功能”的;在SDN网络中,中间的交换机是傻逼,只能通过具有大脑的控制器来指定下发表项,告诉交换机转发的路径才OK。
交换机
纯OpenFlow交换机
混合OpenFlow交换机
虚拟OpenFlow交换机(OVS)
2016/9/9