追踪openvswitch对特定数据报文的流表匹配与处理结果的实例

SDN环境中，每一个openvswitch的datapath实例中都会有大量的流表项，无论是使用各种关键字的grep手段或者是其他方法来确认是否由控制器下发了预期正确流表项，还是看关于特定数据包的匹配与最终action都是一件非常繁琐和头疼的事情。使用ovs-appctl工具结合linux自带的tcpdump抓包工具就可以很轻松直观的最终流表匹配情况，来完成自己繁琐的查找工作，还能避免自己的判断的错误。

?? 主要步骤如下：
? ? 1、确认你需要跟踪的数据包的各项参数；

? ? 2、将其转化成openflow的match域的描述；

? ? 3、使用openvswitch提供的ofproto/trace功能跟踪流表匹配情况；

如何获取包特征参数？
? ? 可以找到自己需要验证的虚拟机，在其上发出需要验证的协议数据包，在物理计算节点上找到该虚拟机的后端虚拟网卡，在该虚拟网卡上使用tcpdump抓包，也可以从已有的抓包文件中获取，当然，也可以完全由自己指定openflow match域的内容。比如我读一下事先抓好的数据包。

[[email protected] ~]# tcpdump -ennvv -r /home/vnet31.0.pcap 

<code?class="language-plain">reading?from?file?/home/vnet31.0.pcap,?link-type?EN10MB?(Ethernet)??
10:25:17.693773?fa:16:3e:8c:eb:5b?>?fa:16:3e:a5:15:f3,?ethertype?IPv4?(0x0800),?length?74:?(tos?0x0,?ttl?128,?id?8060,?offset?0,?flags?[none],?proto?ICMP?(1),?length?60)??
????20.20.20.104?>?20.20.20.101:?ICMP?echo?request,?id?1,?seq?40197,?length?40</code>??

转换成openflow的描述就是：

dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,ip,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_proto=1

由于该虚拟网卡连接openvswitch的ofport 是37，所以要加上?in_port=37,完整的就如下所示：

in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,ip,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_proto=1

确定了数据包的openflow的特征描述，就可以使用ovs-appctl提供的ofproto/trace功能来跟踪啦，命令如下：

[[email protected] ~]# ovs-appctl ofproto/trace dvs2_dp in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,ip,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_proto=1 -generat

其中dvs2_dp是我实测环境中的bridge名称，-generate的意思是构造该数据报文，此时是确实有一个该报文通过ovs被处理了的。最终跟踪的效果下：

[[email protected] ~]# ovs-appctl ofproto/trace dvs2_dp in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,ip,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_proto=1 -generate

Bridge: dvs2_dp
Flow: icmp,metadata=0,in_port=37,vlan_tci=0x0000,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
Rule: table=0 cookie=0xd4 priority=0
OpenFlow actions=goto_table:1

        Resubmitted flow: unchanged
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_frag=no

        Rule: table=1 cookie=0x616 priority=221,in_port=37
        OpenFlow actions=write_metadata:0x3000009c4,goto_table:4

                Resubmitted flow: icmp,metadata=0x3000009c4,in_port=37,vlan_tci=0x0000,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_frag=no

                Rule: table=4 cookie=0x617 priority=161,dl_src=fa:16:3e:8c:eb:5b
                OpenFlow actions=write_metadata:0x3000009c4,goto_table:5

                        Resubmitted flow: unchanged
                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                        Resubmitted  odp: drop
                        Resubmitted  megaflow:
     recirc_id=0,skb_priority=0,icmp,in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_frag=no

                        Rule: table=5 cookie=0xd9 priority=0
                        OpenFlow actions=goto_table:6

                                Resubmitted flow: unchanged
                                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                                Resubmitted  odp: drop
                                Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,metadata=0/0xffffff,in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_frag=no

                                Rule: table=6 cookie=0x5e8 priority=102,metadata=0x9c4/0xffffff,dl_dst=fa:16:3e:a5:15:f3
                                OpenFlow actions=write_actions(set_field:0x9c4->tun_id,output:12)

Final flow: icmp,tun_id=0x9c4,metadata=0x3000009c4,in_port=37,vlan_tci=0x0000,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
Megaflow: recirc_id=0,skb_priority=0,icmp,tun_id=0,metadata=0/0xffffff,in_port=37,dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,nw_src=20.20.20.104,nw_dst=20.20.20.101,nw_ecn=0,nw_frag=no
Datapath actions: set(tunnel(tun_id=0x9c4,src=172.47.205.45,dst=172.47.205.46,tos=0x0,ttl=64,flags(df,key))),11

上面的例子是最终数据包被打上了tun_id并从隧道端口被转发的跟踪，下面再举一个table miss被丢弃的例子：

[[email protected] ~]# ovs-appctl ofproto/trace sdn_dvs_dp in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,ip,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_proto=1 -generate
Bridge: sdn_dvs_dp
Flow: icmp,metadata=0,in_port=127,vlan_tci=0x0000,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
Rule: table=0 cookie=0x1ea priority=0
OpenFlow actions=goto_table:1

        Resubmitted flow: unchanged
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_frag=no
        Rule: table=1 cookie=0x294 priority=221,in_port=127
        OpenFlow actions=write_metadata:0xa00000191,goto_table:4

                Resubmitted flow: icmp,metadata=0xa00000191,in_port=127,vlan_tci=0x0000,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_frag=no
                Rule: table=4 cookie=0x295 priority=161,dl_src=fa:16:3e:a5:85:78
                OpenFlow actions=write_metadata:0xa00000191,goto_table:5

                        Resubmitted flow: unchanged
                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                        Resubmitted  odp: drop
                        Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_frag=no
                        Rule: table=5 cookie=0x1ef priority=0
                        OpenFlow actions=goto_table:6

                                Resubmitted flow: unchanged
                                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                                Resubmitted  odp: drop
                                Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_frag=no
                                Rule: table=6 cookie=0x1f4 priority=111,dl_dst=00:d0:d0:1c:3d:2d
                                OpenFlow actions=goto_table:7

                                        Resubmitted flow: unchanged
                                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0
                                        Resubmitted  odp: drop
                                        Resubmitted megaflow: recirc_id=0,skb_priority=0,icmp,metadata=0/0xffffffff00000000,in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_frag=no
                                        Rule: table=7 cookie=0x1f1 priority=0
                                        OpenFlow actions=CONTROLLER:65535

Final flow: icmp,metadata=0xa00000191,in_port=127,vlan_tci=0x0000,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
Megaflow: recirc_id=0,skb_priority=0,icmp,metadata=0/0xffffffff00000000,in_port=127,dl_src=fa:16:3e:a5:85:78,dl_dst=00:d0:d0:1c:3d:2d,nw_src=192.168.150.2,nw_dst=10.47.159.89,nw_frag=no
Datapath actions: drop
This flow is handled by the userspace slow path because it:
        - Sends "packet-in" messages to the OpenFlow controller.

原文地址：http://blog.51cto.com/smoke520/2314922

时间： 2024-08-29 02:28:49

追踪openvswitch对特定数据报文的流表匹配与处理结果的实例的相关文章

ovs源码阅读--流表查询原理

segmentfault对应博文:https://segmentfault.com/a/1190000016112493 背景 在ovs交换机中,报文的处理流程可以划分为一下三个步骤:协议解析,表项查找和动作执行,其中最耗时的步骤在于表项查找,往往一个流表中有数目巨大的表项,如何根据数据报文的信息快速的查找到对应的流表项是ovs交换机的一个重要的功能. 在openflow协议中,支持多级流表的形式,可以类比于将一个复杂的功能进行打散,分解成过个小的功能,实现一个流水线的功能,具体见下图: 上图中

openflow流表项中有关ip掩码的匹配的问题(控制器为ryu)

一.写在前面 唉,被分配到sdn安全方向,顶不住,顶不住,感觉搞不出来什么有搞头的东西.可若是让我水水的应付,我想我也是做不到的,世上无难事只怕有心人.好了,进入正题,本次要讨论的时一个比较细节的东西,在流表项中的有关ip掩码的问题.对了,本文适合于,有一定基础的openflow使用者,一点点就行. 二.问题描述 若不是机缘巧合,我甚至完全不会注意到这个问题,为什么,咱来看一个平时实验环境中最为常见的流表项长啥样,如图1                                      

OpenvSwitch 流表转换

推荐看一下这篇文章,讲述了各个流表,我们这里着重讲流程和代码,对流表不再细说. 我们主要的关注点还是OVS-DPDK的流表转换,其实和OVS的转换差不多,只不过OVS的Datapath流表位于kernel,报文在Datapath找不到流表即通过netlink上传到Userspace,而OVS-DPDK则是Datapath流表依然位于Userspace,可以看做是一个缓存.查找不到的话直接继续调用其他接口查找Userspace的流表. controller会根据网络情况给ovs下发流表,或者命令o

Openvswitch原理与代码分析(5): 内核中的流表flow table操作

? 当一个数据包到达网卡的时候,首先要经过内核Openvswitch.ko,流表Flow Table在内核中有一份,通过key查找内核中的flow table,即可以得到action,然后执行action之后,直接发送这个包,只有在内核无法查找到流表项的时候,才会到用户态查找用户态的流表.仅仅查找内核中flow table的情况被称为fast path. ? ? 第一步:从数据包中提取出key ? 实现函数为int ovs_flow_key_extract(const struct ip_tun

iptables的基本概念及数据报文在iptables中的流传过程

iptables 高性价比的防火墙 Linux中建立在内核上的防火墙iptables在网络攻击方式和技术日益增多的21世纪,服务器的安全性逐渐显得尤为重要,在主机防护层面相比昂贵的硬件防火墙设备,iptables是一种性价比很高的包过滤型软件防火墙,无需昂贵的费用,只需消耗一定的服务器计算资源. iptables的基本概念 Netfilter:iptables是建立在内核上的防火墙,而NetfilterLinux内核的一个数据处理模块.而iptables就相当于在用户空间对于Netfilter的

Linux多线程实践（四 ）线程的特定数据

在单线程程序中,我们经常要用到"全局变量"以实现多个函数间共享数据, 然而在多线程环境下,由于数据空间是共享的,因此全局变量也为所有线程所共有.但有时应用程序设计中有必要提供线程私有的全局变量,仅在某个线程中有效,但却可以跨多个函数访问.POSIX线程库通过维护一定的数据结构来解决这个问题,这个些数据称为(Thread-specific-data或 TSD). 相关函数如下: int pthread_key_create(pthread_key_t *key, void (*destr

Linux多线程实践(4) --线程特定数据

线程特定数据 int pthread_key_create(pthread_key_t *key, void (*destr_function) (void *)); int pthread_key_delete(pthread_key_t key); int pthread_setspecific(pthread_key_t key, const void *pointer); void * pthread_getspecific(pthread_key_t key); pthread_onc

线程特定数据TSD总结

一线程的本质 二线程模型的引入 三线程特定数据 四关键函数说明 五刨根问底啥原理 六私有数据使用示例 七参考文档 一.线程的本质 Linux线程又称轻量进程(LWP),也就说线程本质是用进程之间共享用户空间模拟实现的. 二.线程模型的引入 线程模型引入是为了数据共享,为什么又引入线程私有数据?有时候想让基于进程的接口适应多线程环境,这时候就需要为每个线程维护一份私有数据了,最典型的就是errno了. 在维护每个线程的私有数据的时候,我们可能会想到分配一个保存线程数据的数组,用线程的ID作为数组的

【网络基础】IP数据报文段解析

IP数据报文段的结构示意图如下: (1)版本 占4位,指IP协议的版本. 通信双方使用的IP协议版本必须一致.目前广泛使用的IP协议版本号为4(即IPv4).关于IPv6,目前还处于草案阶段. (2)首部长度 占4位,可表示的最大十进制数值是15. 请注意,这个字段所表示数的单位是32位字长(1个32位字长是4字节),因此,当IP的首部长度为1111时(即十进制的15),首部长度就达到4*15=60字节.当IP分组的首部长度不是4字节的整数倍时,必须利用最后的填充字段加以填充.因此数据部分永远在