openflow packet_out和packet_in分析

2019/02/12 17:56
阅读数 473

任务目的

1、 掌握OpenFlow交换机发送Packet-in消息过程及其消息格式。 2、 掌握OpenFlow控制器发送Packet-out消息过程及其消息格式。

实验原理

Packet-In

使用Packet-In消息的目的是为了将到达OpenFlow交换机的数据包发送至OpenFlow控制器。以下2种情况即可发送Packet-In消息。

不存在与流表项一致的项目时(Table-miss),OFPR_NO_MATCH 匹配的流表项中记载的行动为“发送至OpenFlow控制器”时,OFPR_ACTION

发送Packet-In消息时OpenFlow交换机分为两种情况,一种是缓存数据包,一种是不缓存数据包。如果不通过OpenFlow交换机缓存数据包,那么Packet-In消息的buffer_id字段设置为-1,将整个数据包发送至OpenFlow控制器。 如果通过OpenFlow交换机缓存数据包,那么以通过SET_CONFIG消息设置的miss_send_len为最大值的数据包数据将发送至OpenFlow控制器。 miss_send_len的默认值为128。未实施SET_CONFIG消息的交换时,使用该默认值。

字段 比特数 内容
buffer_id 32 表示OpenFlow交换机中保存的数据包的缓存id
Total_len 16 帧的长度
in_port 16 接受帧的端口
reason 8 发送Packet-in消息的原因
pad 8 用于调整对齐的填充
data 任意 包含以太网帧的数据时使用的字段。

Packet-Out

Packet-Out消息是从OpenFlow控制器向OpenFlow交换机发送的消息,是包含数据包发送命令的消息”。 若OpenFlow交换机的缓存中已存在数据包,而OpenFlow控制器发出“发送该数据包”的命令时,该消息指定了表示相应数据包的buffer_id。使用Packet-Out消息还可将OpenFlow控制器创建的数据包发送至OpenFlow交换机。此时,buffer_id置为-1,在Packet-Out消息的最后添加数据包数据。

字段 比特数 内容
buffer_id 32 表示OpenFlow交换机中保存的数据包的缓存id
in_port 16 数据包的输入端口
actions_len 16 行动信息的长度

制器与OpenFlow交换机在连接建立过程中会存在拓扑发现的环节,该环节会密集出现Packe-in/out消息,其交互流程如下:

1、 SDN控制器通过构造Packet-out消息,向交换机s1的三个端口分别发送上图所示的LLDP数据包。 2、 控制器向交换机s1下发流表,流表规则为:将从Controller端口收到的LLDP数据包从规定端口发送出去。 3、 控制器向交换机s2下发流表,流表规则为:将从非Controller接收到LLDP数据包发送给控制器。 4、 当LLDP数据包到达交换机s2,会触发Packet-in消息发往控制器。控制器通过解析LLDP数据包,得到链路的源交换机,源接口(s1,port1)。通过收到的Packet-in消息知道目的交换机(s2)。 5、 同理,当SDN控制器向交换机s2发送Packet-out消息时,可以得知链路源交换机,源接口(s2,port3)。通过收到的Packet-in消息知道目的交换机(s1)。如此,控制器便发现了s1与s2之间的完整链路。 对于存在多个交换机的网络,上述分析过程一样成立。

实验步骤

步骤 1

登录控制器,切换至root用户。输入如下命令,启动RYU相关应用。

ryu-manager --verbose --observe-links ryu.topology.switches ryu.app.rest_topology ryu.app.ofctl_rest ryu.app.simple_switch_13

步骤 2

再打开新的命令窗口,切换到root用户。执行wireshark命令启动Wireshark,抓包enp0s17

步骤 3

登录Mininet所在的主机,切换至root用户。执行命令mn —controller=remote,ip=30.0.1.3, port=6633 —switch=ovsk,protocols=OpenFlow13 —topo=linear,2,如下图所示。

步骤 4

执行命令links

步骤 5

登录控制器,停止Wireshark,观察数据包列表,可以看出控制器与交换机的基本交互流程。

Packet in/out消息详解

步骤1 登录Mininet所在的主机,查看交换机s1的流表信息(s2同理):

 ovs-ofctl dump-flows -O OpenFlow13 s1
root@mininet:~# ovs-ofctl dump-flows -O OpenFlow13 s1
 cookie=0x0, duration=495.916s, table=0, n_packets=552, n_bytes=33120, priority=65535,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc actions=CONTROLLER:65535
 cookie=0x0, duration=495.923s, table=0, n_packets=50, n_bytes=4923, priority=0 actions=CONTROLLER:65535

红色标记的流表项中:dl_type=0x88cc表示LLDP帧,dl_dst=01:80:c2:00:00:0e表示目的MAC地址为局域网组播地址actions=CONTROLLER:65535表示行动为发往控制器的65535端口,意味着输入到交换机中的LLDP组播帧都会发送到控制器。

步骤2 在控制器Wireshark抓取的数据包中,寻找包含LLDP包的Packet-out消息并双击,详细信息展示如下。

img 可以看出,该控制器与OpenFlow交换机协商的OpenFlow版本为1.3版本,消息类型为Packet-out。由红色标记部分信息可以看出Packet-out消息中包含LLDP帧,动作为从交换机的端口2发出,以此来检测网络拓扑结构。

步骤3 在控制器Wireshark抓取的数据包中,寻找包含LLDP包的Packet-in消息并双击,详细信息展示如下。

imgLLDP帧被发送至相邻的交换机后,与事先设置好的流表项进行匹配(红色标记表示Packet-in消息触发原因为:匹配的流表项的行动为“发往控制器”),通过Packet-in消息封装LLDP帧,把消息发送到控制器。

步骤4 在控制器中重启Wireshark,准备抓取Packet-in消息。

步骤5 在Mininet主机中,删除交换机s1的流表,同时快速进行Ping操作。

$ sh ovs-ofctl del-flows s1 -O OpenFlow13
$ sh ovs-ofctl dump-flows s1 -O OpenFlow13
$ h1 ping h2

img

步骤6 在控制器中查看Wireshark,添加过滤条件icmp,寻找触发原因为“OFPR_NO_MATCH”的Packet-in消息并双击。该消息的详细情况如下。

img 由于OpenFlow交换机中不存在流表项,故发送到OpenFlow交换机的ICMP包无法匹配流表,只好封装并上传到控制器。红色标记表明该Packet-in消息触发原因为:不存在匹配的流表项(OFPR_NO_MATCH)。

展开阅读全文
打赏
1
0 收藏
分享
加载中
我想问一下,最后一部分步骤五那里,h1 ping h2数据怎么是这样的?ping10.0.0.2,发出也是10.0.0.2????我这一步直接就是h1没法ping通h2,然后也抓不到触发原因为“OFPR_NO_MATCH”的Packet-in消息,抓了半天都只有“OFPR_ACTION”的,有没有什么细节我没搞好?
2020/11/11 13:33
回复
举报
更多评论
打赏
1 评论
0 收藏
1
分享
返回顶部
顶部