实验3：OpenFlow协议分析实践
一、实验目的
1.能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
2.能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
1.下载虚拟机软件Oracle VisualBox；
2.在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；
三、实验要求
（一）基本要求
1.搭建下图所示拓扑，完成相关 IP 配置，并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据包。 |
| 主机 | IP地址 |
|---|---|
| h1 | 192.168.0.101/24 |
| h2 | 192.168.0.102/24 |
| h3 | 192.168.0.103/24 |
| h4 | 192.168.0.104/24 |
#!/usr/bin/env python
from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSController
from mininet.node import CPULimitedHost, Host, Node
from mininet.node import OVSKernelSwitch, UserSwitch
from mininet.node import IVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info
from mininet.link import TCLink, Intf
from subprocess import call
def myNetwork():
net = Mininet( topo=None,
build=False,
ipBase='192.168.0.0/24')
info( '*** Adding controller\n' )
c0=net.addController(name='c0',
controller=Controller,
protocol='tcp',
port=6633)
info( '*** Add switches\n')
s1 = net.addSwitch('s1', cls=OVSKernelSwitch)
s2 = net.addSwitch('s2', cls=OVSKernelSwitch)
info( '*** Add hosts\n')
h1 = net.addHost('h1', cls=Host, ip=' 192.168.0.101/24', defaultRoute=None)
h2 = net.addHost('h2', cls=Host, ip='192.168.0.102/24', defaultRoute=None)
h3 = net.addHost('h3', cls=Host, ip='192.168.0.103/24', defaultRoute=None)
h4 = net.addHost('h4', cls=Host, ip='192.168.0.104/24', defaultRoute=None)
info( '*** Add links\n')
net.addLink(h1, s1)
net.addLink(h3, s1)
net.addLink(s1, s2)
net.addLink(h2, s2)
net.addLink(s2, h4)
info( '*** Starting network\n')
net.build()
info( '*** Starting controllers\n')
for controller in net.controllers:
controller.start()
info( '*** Starting switches\n')
net.get('s1').start([c0])
net.get('s2').start([c0])
info( '*** Post configure switches and hosts\n')
CLI(net)
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
myNetwork()
2.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。 |
HELLO：
-
首先控制器与交换机互相发送HELLO消息，可以看到控制器OpenFlow版本为1.0，交换机OpenFlow版本为1.5，依据向下兼容，使用OpenFlow1.0。
- 控制器6633端口->交换机43552端口：
- 交换机43552端口->控制器6633端口：
FEATURES_REQUEST/SET_CONFIG:
- 控制器6633端口（我需要你的特征信息）->交换机43552端口
- 控制器6633端口（请按照我给你的flag和max bytes of packet进行配置）->交换机43552端口
PORT_STATUS:
- 当交换机端口发生变化时，告知控制器相应的端口状态。
FEATURES_REPLY:
- 交换机43552端口（这是我的特征信息，请查收）->控制器6633端口
PACKET_IN：
- 有两种情况：
- 交换机查找流表，发现没有匹配条目时
- 有匹配条目但是对应的action是OUTPUT=CONTROLLER时
- 交换机43552端口（有数据包进来，请指示）-> 控制器6633端口
- 分析抓取的数据包，可以发现是因为交换机发现此时自己并没有匹配的流表（Reason:
No matching flow (table-miss flow entry) (0)），所以要问控制器如何处理
FLOW_MOD
- 分析抓取的flow_mod数据包，控制器通过6633端口向交换机43552端口、交换机
43554端下发流表项，指导数据的转发处理
- 分析抓取的flow_mod数据包，控制器通过6633端口向交换机43552端口、交换机
43554端下发流表项，指导数据的转发处理
PACKET_OUT：
- 控制器6633端口（请按照我给你的action进行处理）-> 交换机43552端口
-
告诉输出到交换机的65531端口
-
流程图
3.回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？ |
（二）进阶要求
1.将抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义。 |
HELLO:
OpenFlow源码：
struct ofp_header {
uint8_t version; /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length; /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with this packet.
Replies use the same id as was in the request
to facilitate pairing. */
};
struct ofp_hello {
struct ofp_header header;
};
FEATURES_REQUEST:
- 与上述结构体的四个数据类型完全相同
SET_CONFIG:
OpenFlow源码：
struct ofp_switch_config {
struct ofp_header header;
uint16_t flags; /* OFPC_* flags. */
uint16_t miss_send_len; /* Max bytes of new flow that datapath should
send to the controller. */
};
PORT_STATUS:
OpenFlow源码：
struct ofp_port_status {
struct ofp_header header;
uint8_t reason; /* One of OFPPR_*. */
uint8_t pad[7]; /* Align to 64-bits. */
struct ofp_phy_port desc;
};
FEATURES_REPLY:
OpenFlow源码：
struct ofp_phy_port {
uint16_t port_no;
uint8_t hw_addr[OFP_ETH_ALEN];
char name[OFP_MAX_PORT_NAME_LEN]; /* Null-terminated */
uint32_t config; /* Bitmap of OFPPC_* flags. */
uint32_t state; /* Bitmap of OFPPS_* flags. */
/* Bitmaps of OFPPF_* that describe features. All bits zeroed if
* unsupported or unavailable. */
uint32_t curr; /* Current features. */
uint32_t advertised; /* Features being advertised by the port. */
uint32_t supported; /* Features supported by the port. */
uint32_t peer; /* Features advertised by peer. */
};
struct ofp_switch_features {
struct ofp_header header;
uint64_t datapath_id; /* Datapath unique ID. The lower 48-bits are for
a MAC address, while the upper 16-bits are
implementer-defined. */
uint32_t n_buffers; /* Max packets buffered at once. */
uint8_t n_tables; /* Number of tables supported by datapath. */
uint8_t pad[3]; /* Align to 64-bits. */
/* Features. */
uint32_t capabilities; /* Bitmap of support "ofp_capabilities". */
uint32_t actions; /* Bitmap of supported "ofp_action_type"s. */
/* Port info.*/
struct ofp_phy_port ports[0]; /* Port definitions. The number of ports
is inferred from the length field in
the header. */
};
PACKET_IN:
OpenFlow源码：
- 没有匹配
enum ofp_packet_in_reason {
OFPR_NO_MATCH, /* No matching flow. */
OFPR_ACTION /* Action explicitly output to controller. */
};
- 控制器发送包
struct ofp_packet_in {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath. */
uint16_t total_len; /* Full length of frame. */
uint16_t in_port; /* Port on which frame was received. */
uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */
uint8_t pad;
uint8_t data[0]; /* Ethernet frame, halfway through 32-bit word,
so the IP header is 32-bit aligned. The
amount of data is inferred from the length
field in the header. Because of padding,
offsetof(struct ofp_packet_in, data) ==
sizeof(struct ofp_packet_in) - 2. */
};
FLOW_MOD:
OpenFlow源码：
struct ofp_flow_mod {
struct ofp_header header;
struct ofp_match match; /* Fields to match */
uint64_t cookie; /* Opaque controller-issued identifier. */
/* Flow actions. */
uint16_t command; /* One of OFPFC_*. */
uint16_t idle_timeout; /* Idle time before discarding (seconds). */
uint16_t hard_timeout; /* Max time before discarding (seconds). */
uint16_t priority; /* Priority level of flow entry. */
uint32_t buffer_id; /* Buffered packet to apply to (or -1).
Not meaningful for OFPFC_DELETE*. */
uint16_t out_port; /* For OFPFC_DELETE* commands, require
matching entries to include this as an
output port. A value of OFPP_NONE
indicates no restriction. */
uint16_t flags; /* One of OFPFF_*. */
struct ofp_action_header actions[0]; /* The action length is inferred
from the length field in the
header. */
};
struct ofp_action_header {
uint16_t type; /* One of OFPAT_*. */
uint16_t len; /* Length of action, including this
header. This is the length of action,
including any padding to make it
64-bit aligned. */
uint8_t pad[4];
};
struct ofp_match {
uint32_t wildcards; /* Wildcard fields. */
uint16_t in_port; /* Input switch port. */
uint8_t dl_src[OFP_ETH_ALEN]; /* Ethernet source address. */
uint8_t dl_dst[OFP_ETH_ALEN]; /* Ethernet destination address. */
uint16_t dl_vlan; /* Input VLAN id. */
uint8_t dl_vlan_pcp; /* Input VLAN priority. */
uint8_t pad1[1]; /* Align to 64-bits */
uint16_t dl_type; /* Ethernet frame type. */
uint8_t nw_tos; /* IP ToS (actually DSCP field, 6 bits). */
uint8_t nw_proto; /* IP protocol or lower 8 bits of
* ARP opcode. */
uint8_t pad2[2]; /* Align to 64-bits */
uint32_t nw_src; /* IP source address. */
uint32_t nw_dst; /* IP destination address. */
uint16_t tp_src; /* TCP/UDP source port. */
uint16_t tp_dst; /* TCP/UDP destination port. */
};
PACKET_OUT：
OpenFlow源码：
struct ofp_action_header {
uint16_t type; /* One of OFPAT_*. */
uint16_t len; /* Length of action, including this
header. This is the length of action,
including any padding to make it
64-bit aligned. */
uint8_t pad[4];
};
struct ofp_packet_out {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath (-1 if none). */
uint16_t in_port; /* Packet's input port (OFPP_NONE if none). */
uint16_t actions_len; /* Size of action array in bytes. */
struct ofp_action_header actions[0]; /* Actions. */
/* uint8_t data[0]; */ /* Packet data. The length is inferred
from the length field in the header.
(Only meaningful if buffer_id == -1.) */
};
四、个人总结
-
实验难度：适中
-
遇到困难及解决办法：
-
一开始抓包先运行了拓扑再用sudo wireshark命令打开wireshark工具导致不能得到正确的抓包，返回找原因时再次认真阅读老师的实验三pdf有加粗强调需要先开启抓包在构建拓扑。于是先删除原先运行的拓扑，先打开wireshark工具，再用终端运行先前搭建的拓扑后就能够得到正确的抓包。
-
进阶要求阅读openflow.h中的代码对照抓包内容里的参数寻找源码代码实在是太多了，找起来太费劲了，于是全选后复制放入word中使用查找工具，根据关键词查找相应的数据类型后再阅读相应部分的代码，看看相应部分代码是否有列出别的结构体，若有则依照这个结构体的名称再次在word中搜索相应结构体复制出来。
-
-
个人感想：
- 在实验开始之前听老师对openflow协议的一些讲解让我对交换机和控制器的消息交互过程有了初步的了解。老师的讲解中有特别提示一些点让我在进行实验时避开了一些坑，如老师说的搭建拓扑后要修改相应网段。通过观察交换机和控制器消息交互的抓包以及绘制流程图，我对这个过程有了更进一步的了解，进阶要求的寻找源码也让我对抓包的数据类型有了一定的了解，实验的进行让我对openflow协议有了从感性到理性的认识。
