一、实验目的
- 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
- 能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
Ubuntu 20.04 Desktop amd64
三、实验要求
（一）基本要求
1.导入的拓扑文件
#!/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', defaultRoute=None)
h2 = net.addHost('h2', cls=Host, ip='192.168.0.102', defaultRoute=None)
h3 = net.addHost('h3', cls=Host, ip='192.168.0.103', defaultRoute=None)
h4 = net.addHost('h4', cls=Host, ip='192.168.0.104', defaultRoute=None)
info( '*** Add links\n')
net.addLink(h1, s1)
net.addLink(h3, s1)
net.addLink(s1, s2)
net.addLink(s2, h2)
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])
CLI(net)
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
myNetwork()
wireshark抓包的结果截图和对应的文字说明
1.hello
控制器6633端口（我最高能支持OpenFlow 1.0） ---> 交换机57520端口
交换机57520端口（我最高能支持OpenFlow 1.5） ---> 控制器6633端口
于是双方建立连接，并使用OpenFlow 1.0
2.Feature Request / Set Config
控制器6633端口（我需要你的特征信息） ---> 交换机57520端口
控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机57520端口
3.Port_Status
当交换机端口发生变化时，告知控制器相应的端口状态。
4.Features Reply
交换机57520端口发送“这是我的特征信息，请查收”信息给控制器的6633端口
5.Packet_IN
有两种情况：
交换机查找流表，发现没有匹配条目时
有匹配条目但是对应的action是OUTPUT=CONTROLLER时
交换机57520端口（有数据包进来，请指示）--- 控制器6633端口
6.Flow_Mod
分析抓取的flow_mod数据包，控制器通过6633端口向交换机57520端口 下发流表项，指导数据的转发处理
7.Packet_Out
控制器6633端口（请按照我给你的action进行处理） ---> 交换机57520端口
2.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图
3.回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？
TCP协议
（二）进阶要求
查看的openflow.h头文件
/*数据包头通用字段*/
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_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. */
};
n_buffers表示交换机缓冲区可以缓存的最大数据包个数
n_tables表示流表数量
pad作为一个填充值
capabilities表示支持的特殊功能
actions:表示支持的动作
port data表示物理端口描述列表
1.hello
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;
};
Hello报文对应的四个参数
2.Feature Request
/* Switch features. */
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. */
};
3.Set config
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. */
};
4.Port_Status
/* A physical port has changed in the datapath */
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;
};
5.Features Reply
/* Switch features. */
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. */
};
6.Packet_IN
有两种情况：
(1)交换机查找流表，发现没有匹配条目时
/* Why is this packet being sent to the controller? */
enum ofp_packet_in_reason
{
OFPR_NO_MATCH, /* No matching flow. */
OFPR_ACTION /* Action explicitly output to controller. */
};
(2)有匹配条目但是对应的action是OUTPUT=CONTROLLER时
交换机35534端口（有数据包进来，请指示）--- 控制器6633端口
/* Packet received on port (datapath -> 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. */
};
7.Flow_Mod
/* Flow setup and teardown (controller -> datapath). */
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. */
};
8.Packet_Out
/* Send packet (controller -> datapath). */
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.) */
};
个人总结
这次实验主要是分析了Openflow协议格式，里面的各个字段以及交换机和控制器的交互过程，难度不大，但是逐个包进行分析比较繁琐，需要有足够的耐心，将抓到的包和Openflow的源码进行对比分析
相关内容整理如下表：
| 数据包 | 作用 |
|---|---|
| OFPT_HELLO | 建立OpenFlow连接， 控制器与交换机互相发送Hello消息，Hello消息中只包含Openflow Header，双方Openflow版本需要兼容（双方所支持的最高版本） |
| FEATURES_REQUEST | 控制器向交换机发送FEATURES_REQUEST询问交换机信息 |
| SET_CONFIG | 控制器向交换机发送发送SET_CONFIG消息以发送设置信息，也可能发送GET_CONFIG请求消息以查询OpenFlow交换机的设置状态 |
| PORT_STATUS | 当交换机端口发生变化时，告知控制器相应的端口状态 |
| FEATURES_REPLY | 交换机收到FEATURES_REQUEST之后随即发送FEATURES_REPLY，将自己的信息发送至控制器 |
| PACKET_IN | 使用Packet-In消息的目的是为了将到达OpenFlow交换机的数据包发送至OpenFlow控制器。以下2种情况即可发送Packet-In消息。不存在与流表项一致的项目时（Table-miss），OFPR_NO_MATCH；匹配的流表项中记载的行动为“发送至OpenFlow控制器”时，OFPR_ACTION |
| PACKET_OUT | Packet-Out消息是从OpenFlow控制器向OpenFlow交换机发送的消息，是包含数据包发送命令的消息 |
| FLOW_MOD | 控制器通过向交换机发送FLOW_MOD，来对交换机进行流表的添加、删除、变更等设置操作 |