SDN实验三 OpenFlow协议分析

Posted 2020-12-09 kl107

此为中国大学MOOC上温州大学所开设的SDN软件定义网络课程配套实验。

实验步骤：

1、利用可视化界面搭建拓扑

 

 

 

2、开启各机器，打开wireshark进行抓包，查看交换机与控制器通讯过程

控制器端口为6633，所以源端口为6633的是控制器。

　　（1）交换机和控制器建立完Socket通道后，会互相发送Hello报文来协商协议版本。

 

　　（2）控制器向交换机下发 Features Request 报文,交换机则需回复 Feature Reply 报文。SET_CONFIG报文为控制器向交换机发送的配置报文。PORT_STATUS为交换机向控制器发送的端口状态改变报文。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

　　（3）交换机对于没有匹配到流表的流向控制器发送packet-in报文。

　　（4）控制器向交换机返回Packet-out报文指明动作或发送flow-MOD报文

　　　　1）Packet_out报文

　　　　2)Flow_mod报文

　　（5）控制器和交换机通过ECHO_REQUEST和ECHO_REPLY报文维持连接。

　　　　1)ECHO_REQUEST

　　　　2)ECHO_REPLY

　　　　

　　3、OpenFlow协议报文说明

OpenFlow 协议支持三种信息类型：Controller-to-Switch，Asynchronous 和 Symmetric，

每一个类型都有多个子类型。Controller-to-Switch 信息由控制器发起并且直接用于检测交换机的状态。Asynchronous 信息由交换机发起并通常用于更新控制器的网络事件和改变交换机的状态。Symmetric 信息可以在没有请求的情况下由控制器或交换机发起。

1）Controller-to-Switch 报文

Controller-to-Switch 报文是由控制器初始化并下发给交换机的报文类型，其可能会要求交换机回复相应的报文，此类型报文包含的主要报文类型介绍如下：

• Features 类型的报文分为 Request 和 Reply 两种，其中控制器可以主动初始化并发送 Features_Request 报文，请求交换机回复其特性信息，其报文只有数据报头，没有消息体（Body）。交换机在收到 Features_Request 报文之后，将通过 Features_Request 报文回复交换机的特性和交换机端口的特性信息.通常，控制器会在交换机的 Openflow 连接建立完成之后马上发送一个请求报文来获取交换机的特征信息。
• Configuration:其包含请求、回复和设置三种报文。控制器可以设置和请求交换机的配置信息,交换机则需执行配置和回复配置报文。
• modify-state:修改状态型报文由控制器下发,用于修改交换机的流表、组表、Meter 表及端口状态 。
• Read- State:读取状态信息由控制器发出,用于获取交换机的状态信息,包括流表、组表、 Meter Table 及端口的统计信息。
• packet-out: packet-out 类型报文由控制器发出,用于将数据包发送到交换机的指定端口。 Packet-out 报文一般用于响应 packet-in 报文的处理,经常跟随在 Flow-mod 报文之后,用于指挥交换机将缓存数据发送或直接发送数据。 packet-out 必须携带一个 Buffer id 来定位缓存在交换机上的数据,当 Buffer id 为-1 时,表明该数据包没有被交换机缓存。此外, Packet-out还需要携带指导数据处理的动作集,如果动作集为空则交换机会将数据包丢弃。
• Barrier: Barriers Request/Reply 用于确保操作顺序执行。控制器可以向交换机发送Request 报文。交换机接收到 Request 报文之后,将 Request 报文之前所有的报文处理完成之后,处理 Barrier Request 请求:回复控制器一个 Barrier Reply 报文,其报文 ID 和请求报文一致,告知控制器在 Barrier Request 报文之前到来的报文已经处理完成。 Barrier 类型的报文类似设置一个障碍或者触发器,用来告知控制 Barrier 之前的动作均已执行,其通常用来确保动作执行顺序,保持策略一致性。
• Role-request:此类型报文用于控制器请求其自身在交换机端的角色,也可以用于设置控制器的角色。一般用于交换机与多控制器有连接的场景。
• asynchronous-configuration:异步配置报文可以用来设置异步报文的过滤器,从而使得在多控制器场景下,控制器可以选择性过滤异步报文,只接收感兴趣的报文。一般在 Open Flow连接建立完成之后进行设置。

2) Asynchronous 报文

　　　　　 Asynchronous 报文是由交换机异步发送给控制器的报文,无须等待控制器请求。交换机通过异步报文告知控制器新数据包的到达和交换机状态的改变。主要的异步报文类型描述如下。

• packet-in:将数据包发送给控制器。在支持单流表的 Open Flow 协议版本中,触发 Packet-in的原因可能是流表项的动作指导,也可能是因为匹配不到流表项。但在高版本的多级流表设计下,将默认下发一条 Table-Miss 流表项,其匹配域均为空,任何报文都能匹配成功。
• Table-Miss 的作用是将匹配其他流表失败的数据发送给控制器。若交换机配置信息中指示将数据包缓存在交换机中,则 Packet-in 报文还将携带着指定长度的数据包数据及其在交换机上缓存的 Buffer  id,携带的数据包默认长度是 128 字节。若交换机不缓存数据包,则由 Packet-n报文携带全部数据并发送给控制器。 packet-in 报文通常会触发 packet-out 报文或者flow-mod 报文。
• Flow- Removed:当 OFPFF SEND FLOW REM 标志位被置位时,交换机将会在流表项失效时通知控制器流表项被移除的消息。触发流表项失效的原因可以是控制器主动删除或者流表项超时。
• Port-status：当端口配置或者状态发生变化时,用于告知控制器端口状态发生改变Role- status:当控制器的角色发生变化时,交换机告知控制器其角色变化。Controller- Status:当 OpenFlow 连接发生变化时,告知控制器这个变化。Flow- monitor:告知控制器流表的改变。控制器可以设置一系列监视器来追踪流表的变化。

3) Symmetric 报文

• Symmetric 可以由控制器和交换机双方任意一方发送,无须得到对方的许可或者邀请。主要类型的介绍如下。
• Hello：Hello 报文用于交换机和控制器之间的 Open Flow 通道建立初期,用于协商版本等内容。
• Echo: Echo Request/Reply 可以由交换机和控制器任意一方发出。每个 Request 报文都需要一个 Reply 报文回复。其主要用于保持连接的活性,但同时也支持携带消息内容,可用于时延或带宽测试。
• Error:错误报文用于交换机或控制器,告知对方错误。一般而言,多被用于交换机告知控制器请求发生的错误。
• Experimenter:实验报文是提供 OpenFlow 报文功能范围之外功能的标准方式可以用于实验场景。