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的流表走势图
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,从虚机端口出去。
对于复杂的场景,一般来说,在查看流表的过程中,还需要结合抓包进行分析。