OVS流表分析方法总结(超实用)

2022-02-18 17:16:36 浏览数 (1)

1、基本流表介绍

在实际应用中,其中查看最多的是0、17、51、220。

编号

表项

操作功能

0

起始流表

端口流表起点

17

端口调度流表

流表调度进匹配转发或者进安全组

50

源mac匹配流表

省略

51

目的mac匹配流表

精确转发到220

210

进端口ACL反欺骗流表

匹配metadata、源mac和源ip

211

进端口ACL连接追踪分类流表

特殊协议分类

212

进端口ACL连接追踪发送流表

送去连接追踪

213

INGRESS_ACL_FOR_EXISTING_TRAFFIC_TABLE

送到214

214

进端口ACL过滤转发流表

根据连接追踪状态判断是否丢弃或者调度:1.通过安全组则调度到17;2.判断未建立追踪状态则调度到212;3.特殊情况调度到217;

216

进端口远端安全组流表

匹配与本端口在同一安全组下的端口

217

进端口ACL提交流表

部分丢弃,部分提交到17,有点类似214的补充

220

出口流表

流表出口,丢弃或者去指定端口

239

EGRESS_ACL_DUMMY_TABLE

清除连接追踪状态

240

出ACL反欺骗流表

匹配reg6、目的mac和目的ip

241

出端口ACL连接追踪分类流表

特殊协议分类

242

出端口ACL连接追踪发送流表

送去连接追踪

243

EGRESS_ACL_FOR_EXISTING_TRAFFIC_TABLE

送到244

244

出端口ACL过滤转发流表

根据连接追踪状态判断是否丢弃或者调度:1.通过安全组则调度到220;2.判断未建立追踪状态则调度到242;

245

进端口ACL规则基本过滤流表

分一下ip或者ipv6然后进入246

246

出端口远端安全组流表

匹配与本端口在同一安全组下的端口

247

出端口ACL过滤转发流表

部分丢弃,部分提交到220,有点类似244的补充

2、使用odl_l2和原生l3的流表走势图

odl_l2和原生l3的流表走势图odl_l2和原生l3的流表走势图

3、具体流表阅读方法

流表的阅读可以分为两个部分:匹配和动作。匹配是指在一堆流表中找到包所走的那条流表,动作是指这个包接下来的操作。

匹配涉及到的字段:priority、in_port、metadata、dl_dst、reg6等

动作涉及到的字段:write_metadata、goto_table、drop、output、load等

上述字段中metadata和write_metadata是最重要的匹配字段,在匹配操作中进行精确匹配,在动作操作中进行写更新。metadata具体形式为字节码/掩码的形式,在操作过程中,掩码位为1的字节段决定匹配段和写入段。

例如metadata=0x170000000000/0xffffff0000000001,掩码与后,得到前面的0x17和末尾的0。前面的0x17是指与网络相关的基本信息,这部分可以很长,通过掩码截取后,主要可以分为网络段(reg7记录)、端口段(reg1/reg6记录),这样划分可以在某些table中便于查看,例如table51以网络段匹配为主,table220以端口段匹配为主等。末尾的0是指,在table0中,包从该端口出,如果是1,就指包从该端口进。(0出1进)

下面就具体的流表进行分析。

cookie=0x8000000, duration=3853.011s, table=0, n_packets=142, n_bytes=13430, priority=10,in_port="br-vlan-patch",dl_vlan=723 actions=pop_vlan,write_metadata:0x4d0000000001/0xffffff0000000001,goto_table:17

关注标红的部分。匹配部分主要有四个字段:table、priority、in_port、dl_vlan。具体内容是,该流表位于起始流表table0,优先级为10,属于vlan的patch口(注意in_port的值有时候是数字,需要查看show-port脚本对应的端口名称),对应的vlan id为723。也就是说,只有属于723的vlan网络的中的报文才会从该host的vlan patch口进入。动作部分主要有三个字段:pop_vlan、write_metadata、goto_table。具体内容是,弹出vlan id,然后按照规则写metadata,最后跳转到table17。

cookie=0x8040000, duration=5547.489s, table=17, n_packets=7, n_bytes=1284, priority=10,metadata=0xb000550000000000/0xffffff0000000000 actions=load:0x55->NXM_NX_REG10..19,load:0x1395->NXM_NX_REG70..15,write_metadata:0xc000551395000000/0xfffffffffffffffe,goto_table:43

关注标红的部分。匹配部分主要有table、priority、metadata。具体内容是,该流表位于table17,匹配0xb00055。动作部分主要有:load、write_metadata、goto_table。具体内容是端口段写入reg1,网络段写入reg7,然后写metadata,最后跳转到table43。

cookie=0x8031393, duration=5594.128s, table=51, n_packets=51, n_bytes=6276, priority=20,metadata=0x1393000000/0xffff000000,dl_dst=fa:16:3e:43:bd:5e actions=load:0x4d00->NXM_NX_REG6[],resubmit(,220)

关注标红的部分。匹配部分主要有table、priority、metadata、dl_dst。具体内容是,该流表位于table51,匹配metadata对于网络段为0x1393(table51的metadata主要就是匹配网络用的),但是匹配网络段为0x1393的流表会有很多,此时再匹配dl_dst目的mac地址,就可以过滤出所走的流表。动作部分主要有:load、resubmit。具体内容是,将目标端口段写入reg6,然后跳转到table220。

cookie=0x8000007, duration=82764.893s, table=220, n_packets=0, n_bytes=0, priority=9,reg6=0x1400 actions=output:tun723446dd7af

关注标红的部分。匹配部分主要是table和reg6。具体内容是,table220的一条流表,匹配端口段为0x1400。动作部分主要是output,从tun723446dd7af口出去。

group_id=210018,type=all,bucket=actions=group:210017,bucket=actions=load:0x3d00->NXM_NX_REG6[],resubmit(,220)

关注标红的部分。这条流表是group的流表,入口一般在flow里的table52,其功能是进行广播。可以看到它的匹配字段是group_id。动作字段则是几个actions,跳转到group:210017,写reg6后跳转到table220。

实际流表还有更多其他的形态,字段和内容也会有较大的变化,但是基本的构造——匹配和动作是不会改变的,只是具体的操作上有所差别,望举一反三。

4、实战操作

这里给出一个示例流程,说明报文是如何通过流表从table0转到table220出去的。

cookie=0x8000000, duration=258.784s, table=0, n_packets=222, n_bytes=21866, priority=10,in_port=6,dl_vlan=233 actions=pop_vlan,write_metadata:0x5e0000000001/0xffffff0000000001,goto_table:17

报文从vlan的patch口进来,写入medata为0x5e0000000001,跳转到table17。

cookie=0x8040000, duration=354.054s, table=17, n_packets=331, n_bytes=32718, priority=10,metadata=0x5e0000000000/0xffffff0000000000 actions=load:0x5e->NXM_NX_REG10..19,load:0x1397->NXM_NX_REG70..15,write_metadata:0xc0005e1397000000/0xfffffffffffffffe,goto_table:43

匹配中流表后,继续写metadata,跳转到43。

流表43到流表51的过程忽略,自行查看。

cookie=0x8031397, duration=448.037s, table=51, n_packets=391, n_bytes=40081, priority=20,metadata=0x1397000000/0xffff000000,dl_dst=fa:16:3e:0f:6c:19 actions=load:0x5f00->NXM_NX_REG6[],resubmit(,220)

匹配metadata发现,有多条匹配。分析该报文的属性可以知道,该报文是一个reply报文,会回到发起ping包的虚机端口。因此找到虚机的端口mac,匹配中。写reg6,跳转到220。

cookie=0x6900000, duration=479.333s, table=220, n_packets=457, n_bytes=46325, priority=6,reg6=0x5f00 actions=load:0x90005f00->NXM_NX_REG6[],write_metadata:0/0xfffffffffe,goto_table:239

匹配中reg6,继续写reg6,跳转端table239,进行端口安全的过滤。

端口安全内的流表跳转忽略,顺利通过,回到table220。

cookie=0x8000007, duration=484.570s, table=220, n_packets=453, n_bytes=44073, priority=9,reg6=0x90005f00 actions=output:"tapd9fd9aa5-d1"

匹配中reg6,从虚机端口出去。

对于复杂的场景,一般来说,在查看流表的过程中,还需要结合抓包进行分析。

0 人点赞