文章目录 架构概述 OpenFlow Switch Pipeline Flow Table Entry Instruction OpenFlow Switch Protocol 测试验证 Pipeline Flow Table Entry Instructions
架构概述 我们知道网络虚拟化的主要目标就是让报文可以在虚拟机之间进行传输。要实现这个目标，个人总结，需要具备这三个要素：虚拟机、报文收发能力和报文转发能力。我们在网络虚拟化基本原理中提到了这个观点。 以上三个要素可以在一个节点的ovs网络环境下实现虚机之间的报文传输，但怎么让各个节点独立的网络连接起来；屏蔽节点间物理网络；并虚拟机提供统一扁平的、与物理网络类似的L2层网络能力，还需要有大量的软件实体参与。具备了为虚机提供与物理网络类似的能力后，还需要支持工程化配置网络节点并支持各组件间松耦合保证可以独立升级演进。梳理以上种种产品化需求，ONF（Open Networking Foundation）提出了软件定义网络SDN（software defined networking）并设计发布了软件定义网络的架构SDN architecture，定义了SDN架构下各软件模块的核心功能、模块实现规范以及模块间的接口或协议，用于进一步指导各子模块的设计与开发。 架构图 SDN架构中把可以通过接口管理虚拟机间网络流量的软件实体称作网络元素（Network element），把专门管理NE的软件实体称作控制器（SDN controller），控制器之上则是应用软件（SDN application），整个架构如下：
SDN控制器和应用程序之间通过北向接口交互，为应用提供必要的管理接口，SDN控制器和各NE之间通过南向接口交互，通过南向接口实现对NE的配置与管理。我们知道在具体实现各组件时，openvswitch作为一种OpenFlow Switch规范的具体实现，可以看成一个NE，SDN controller和OpenFlow Switch之间的关系如下图所示： 核心组件 从上面的架构中可以看到SDN架构下的网络虚拟化核心组件有如下三个，我们分别简述其作用： SDN Controller，负责控制底层各NE，在OpenFlow Switch规范的实现里，负责下发switch的配置信息，流表信息等，从而控制switch处理报文的行为。 OpenFlow Protocol，定义Controller和Switch之间配置信息、流表信息传递的规范，Controller按照此规范下发各种控制信息，Switch按照此规范接收并处理控制信息。 OpenFlow Switch，定义可以通过流表控制包处理的交换机规范，openvswitch即该规范的一种软件实现，负责虚拟机之间报文的处理与转发。 OpenFlow Switch OpenFlow定义了一种通过流表控制的交换机的实现规范，即OpenFlow Switch规范。相比传统物理交换机通过硬件控制交换机处理包的行为，通过流表控制包处理行为的交换机为软件实现，配置更加灵活并且能够提供更丰富的功能与接口，用于支持上层实现更高级的网络特性。 这一节我们主要介绍规范中实现OpenFlow交换机需要遵守的工作流程（Pipeline）、流表项需要定义的核心字段（Flow Table Entry）以及报文处理的指令流程（Instruction）。 Pipeline 从上一章中OpenFlow Switch的架构图中我们知道，Switch接收从入端口来的报文，处理后将其从出端口发送出去，整个过程可以看做是一个流水线，交换机规范中定义流水线的处理逻辑如下： 交换机中的流表可以有多张，每张流表由多条流表项组成，在最简单的流水线中，交换机至少有一张入向流表用于处理入向端口的报文。流水线包含一张或多张流表，定义了经过该流水线的报文如何被处理。简单描述：报文从交换机入口进入，从流表0开始按照OpenFlow Switch规范中描述的匹配逻辑，按照序号从低到高逐一匹配所有流表直到从交换机出口被转发出去，匹配流表时会逐一匹配每个表项，成功后按照表项要求将需要执行的操作添加到Action Set，在所有流表匹配完成后，取出Action Set中所有操作逐一执行。Action Set从一开始的空集，随每个包在流表项中被逐一匹配后，逐渐增多，最后在Ingress 处理流程的最后阶段统一执行。 具体来说，报文的处理逻辑基于流表项的匹配机制，流程图如下： 报文从入向端口进入后，总是从流表0开始，按照流表编号从低到高逐表进行匹配（不可逆），在匹配每张流表时会逐一查询表中每条表项。匹配结果只有两种，一是报文匹配流表项成功，则执行匹配流表项中定义的指令；二是报文匹配所有流表都失败，则检查交换机是否配置Table-miss这个特殊的流表项，如果有配置，则按照流表项中的指令执行，通常有几种行为，丢弃报文、转发报文到其它流表继续匹配、通过控制通道发送报文到controller；如果没有配置，则丢弃报文。 报文成功匹配流表项之后，交换机Pipeline就会更新表项中的统计信息，同时执行流表项中的指令，完成之后报文的行为可能有两种，根据流表项中的指令跳转到下一个流表继续进行匹配，或者不再跳转执行直接进入到最后阶段，执行流表匹配过程中累计添加到Action Set中的操作。 Action Set中最后一个要执行的操作总是output转发操作，如果output操作不存在，但包含group操作，则进入另一个由group描述的Action Set，如此迭代执行。如果output和group都不存在，丢弃报文。Action Set中包含output操作的情况下，如果交换机不包含出向的流表，则直接从端口出去，如果包含出向流表，则需要重复1-3类似的流程，最终从端口转发出去或者执行其它操作。Flow Table Entry 流表项是OpenFlow Switch规范最核心的设计，其格式如下： 我们简要介绍流表项重要字段的含义： Match Fields，匹配域，用于匹配报文，匹配的信息主要有两类，一类是报文头部信息，比如以太网帧头部或IP报文头部等，另一类是Pipeline上下文相关的信息，比如入向端口、流表附加元数据信息等。在OpenFlow Switch的Pipeline中被处理的报文，与普通报文相比还会被交换机增加Pipeline特有的一些信息用来匹配流表项，比如报文的入向端口，元数据等，我们称之为Pipeline fields。 Priortiy，优先级，优先级和匹配域两个字段信息共同组成流表项的ID，当匹配域的信息相同时，优先选择优先级高的流表项。 Counters，统计字段，用于存放统计信息，统计信息的类型有多种，基于整个流表的统计、基于流表项的统计、基于端口的统计、基于队列的统计等等。基于流表的统计信息包括如匹配成功次数、查询次数；基于流表项的统计信息包括接受的报文包个数、字节数等等。 Instructions，指令集，报文与流表项匹配成功后需要执行指令集合，指令操作主要有三类，一类是立即执行集合中的操作（Apply-Actions action），比如修改报文头、更新Pipeline fields中的信息；第二类是针对Action Set的操作，包括对集合的增、删；另一类就是跳转到其它流表操作。 Instruction 报文成功匹配流表项之后，会读取流表项中的指令信息并执行相应指令，流表的匹配和执行流程如下图所示： 报文的流表匹配步骤如下： 交换机提取报文的头部信息，同时为报文关联对应的Pipeline Fields和Action Set，整个流表匹配过程中，会用到这三类数据。 交换机提取头部信息后，将头部信息和Pipeline Fields一起，作为匹配流表项的信息，逐一匹配每个表项。 交换机匹配流表项成功后，提取并执行指令字段描述的指令。 指令执行主要分为三类，一类是操作执行类指令，指令类型为Apply-Actions，执行这类指令可能会修改报文头，更新匹配域或者报文关联的Pipeline Fields等等；第二类是对Action Set集合的增删操作；第三类是跳转到其它流表操作。 报文的最终流向受指令执行结果影响，当流表项的指令中没有流表跳转指令，即报文匹配到最后一张流表，则会执行报文关联的Action Set集合中的所有操作。流表项匹配成功后，指令的执行会不断增删Action Set集合，其最终结果受此影响。 报文匹配成功后会执行指令，如果执行的指令类型为Apply-Actions，则会执行具体操作Action，如果操作类型为output，则会将报文从端口转发出去，如果有出向流表，则报文会继续匹配。 OpenFlow Switch Protocol OpenFlow channel是交换机对外提供的与控制器连接的接口，通过该接口，控制器可以配置与管理交换机，交换机可以上报 事件给控制器。OpenFlow Switch规范规定，前述功能的实现必须遵守OpenFlow Switch Protocol（以下简称OpenFlow协议）。 交换机协议定义了三类消息类型，如下： controller-to-switch：该类消息由控制器发起，主要功能是传递控制器下发的管理和查询信息 synchronous：该类消息由交换器发起，主要功能是同步交换机中发生的网络事件和交换机状态到控制器 symmetric：该类消息两侧都可以发起 我们最关心的流表下发消息属于controller-to-switch消息，下图展示了同属controller-to-switch消息类型的两个子类消息，分别是流表修改（OFPT_TABLE_MOD）和流表项修改（OFPT_FLOW_MOD）。通过发送OFPT_TABLE_MOD类型消息给交换机，控制器可以实现流表属性的修改操作，通过发送OFPT_FLOW_MOD类型消息给交换机，控制器可以实现流表项的增加、删除和修改等操作。 测试验证 OpenFlow Switch支持的功能太多，我们选取最感兴趣的三个技术点进行设计验证，包括Pipeline流程验证、流表项匹配验证和指令执行验证。最后我们还想抓取OpenFlow Switch Protocol消息，验证消息格式是否满足OpenFlow Switch Protocol。 Pipeline pipeline的验证环境只有一个桥接ovs的虚拟机，我们通过ping包验证ovs的流水线流程，分两个方面，一是验证同一流表，报文在流表项间的匹配流程，另一个是同一个Ingress pipeline，报文在流表间的匹配流程。虚拟机网卡为vnet0，它与ovs桥关系如下： [root@Hyman_server1 ~]# virsh domiflist c81_node1 Interface TypeSourceModelMAC------------------------------------------------------------- vnet0 bridgevsvirtio 24:42:53:21:52:4e vnet1 network default virtio 24:42:53:20:50:45[root@Hyman_server1 ~]#ovs-vsctl showf1011f20-73a8-44f1-979e-bc4fd82a106fBridge vsPort vsInterface vstype: internalPort "vnet0"Interface "vnet0"ovs_version: "2.11.0"流表项间流程 ovs创建后，默认会在table 0创建一条流表项entry 0，这条流表匹配所有的报错并将其按照物理交换机的行为对报文进行处理，我们的验证流程非常简单，在table 0中增加一条优先级比流表entry 1，它匹配所有报文并将其丢弃，如下图所示： 查看ovs流表和流表项如下： [root@Hyman_server1 ~]# ovs-ofctldump-tables vsOFPST_TABLE reply (OF1.3) (xid=0x2):table 0:active=1, lookup=12675, matched=12609table 1:active=1, lookup=6666, matched=6580table 2:active=0, lookup=0, matched=0tables 3...253: ditto[root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=0 cookie=0x0, duration=865.777s, table=0, n_packets=1790, n_bytes=169820, priority=0 actions=NORMAL[root@Hyman_server1 ~]# ip addr show dev vs[root@Hyman_server1 ~]# ip addr show dev vs4: vs: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000link/ether 26:44:42:8c:47:4e brd ff:ff:ff:ff:ff:ffinet 10.10.10.195/24 brd 10.10.10.255 scope global vs valid_lft forever preferred_lft forever[root@s1_vm1 ~]# ip add show dev ens73: ens7: mtu 1500 qdisc fq_codel state UP group default qlen 1000link/ether 24:42:53:21:52:4e brd ff:ff:ff:ff:ff:ffinet 10.10.10.196/24 brd 10.10.10.255 scope global noprefixroute ens7 valid_lft forever preferred_lft forever从虚机内部ping主机vs桥，可以正常通信，虚机内部发送2个icmp包，主机上vs交换机table 0的entry 0对对应匹配4个icmp包（request和reply），如下所示： 现在我们在table 0上增加一条表项ovs-ofctl add-flow vs "priority=1,table=0,actions=DROP"，则按照规范定义，表项0和表项1都可以匹配任何报文，这种情况下，优先级高的表项会被流水线选择并执行其对应的指令，因此可以判断该表项增加后ping包的变化有几点： 报文将会被丢弃 entry 0将不会被匹配，因此其统计数据不会更新 entry 1将会被匹配，其统计数据会更新，但由于表项匹配request报文后会执行指令将其丢弃，因此reply报文不会被匹配 流表间流程 流表间流程验证也非常简单，我们验证的两个场景如下图所示： 第一个场景我们在table 1中添加一条普通交换机流表项ovs-ofctl add-flow vs "priority=0,table=1,actions=NORMAL"，然后修改table 0中的流表项 entry 1，将其drop的行为修改为goto_table，让其跳转到table 1继续处理，流表项操作如下： [root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=0 cookie=0x0, duration=3735.372s, table=0, n_packets=2282, n_bytes=214992, priority=0 actions=NORMAL cookie=0x0, duration=1053.146s, table=0, n_packets=17, n_bytes=826, priority=1 actions=drop[root@Hyman_server1 ~]# ovs-ofctldel-flows vs table=0[root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=0[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=0,table=0,actions=NORMAL"[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=1,table=0,actions=goto_table:1"[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=0,table=1,actions=NORMAL"[root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=0 cookie=0x0, duration=29.879s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL cookie=0x0, duration=12.290s, table=0, n_packets=0, n_bytes=0, priority=1 actions=goto_table:1[root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=1 cookie=0x0, duration=8.473s, table=1, n_packets=6580, n_bytes=622160, priority=0 actions=NORMAL增加流表项之后我们现象如下： 可以看到修改流表项之后虚机内部ping包正常，主机侧交换机上table 0的entry 1和table 1的entry 0统计数据有更新，匹配到了报文，和预期一样，table 0上entry 0虽然可以匹配任何报文，但优先级没有table 0的entry 1高，因此没有匹配到任何报文，统计数据未更新。 第二个场景我们对流表项做两处修改，一是在table 2中新增一条NORMAL流表，二是让table 0中原来跳转到table 1的流表项entry 1跳转到table 2，可以预计，这样修改后，虚机内部通信仍然正常，但table 1中的流表项不会再匹配到报文，只有table0和table 2可以匹配，流表项的修改如下： [root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=0 cookie=0x0, duration=752.154s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL cookie=0x0, duration=734.565s, table=0, n_packets=24, n_bytes=1680, priority=1 actions=goto_table:1[root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=1 cookie=0x0, duration=731.350s, table=1, n_packets=6604, n_bytes=623840, priority=0 actions=NORMAL[root@Hyman_server1 ~]# ovs-ofctldump-flows vs table=2[root@Hyman_server1 ~]# ovs-ofctldel-flows vs table=0[root@Hyman_server1 ~]# ovs-ofctldump-flows vs cookie=0x0, duration=748.760s, table=1, n_packets=6604, n_bytes=623840, priority=0 actions=NORMAL[root@Hyman_server1 ~]# ovs-ofctldel-flows vs table=1[root@Hyman_server1 ~]# ovs-ofctldump-flows vs[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=0,table=0,actions=NORMAL"[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=1,table=0,actions=goto_table:2"[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=0,table=1,actions=NORMAL"[root@Hyman_server1 ~]# ovs-ofctl add-flow vs "priority=0,table=2,actions=NORMAL"[root@Hyman_server1 ~]# ovs-ofctldump-flows vs cookie=0x0, duration=29.547s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL cookie=0x0, duration=18.605s, table=0, n_packets=0, n_bytes=0, priority=1 actions=goto_table:2 cookie=0x0, duration=10.962s, table=1, n_packets=0, n_bytes=0, priority=0 actions=NORMAL cookie=0x0, duration=5.784s, table=2, n_packets=0, n_bytes=0, priority=0 actions=NORMALFlow Table Entry 测试环境我们启动两个虚机，桥接同一个ovs，我们主要验证流表项的报文匹配功能，流水线的流表项如下图所示： 我们分别解释每条流表项的意义： table 0, entry 0: 匹配任何报文，成功匹配后执行normal操作。 table 0, entry 1: 匹配发往目的IP为10.10.10.197的icmp请求报文。其中dl_type=0x800，表示匹配IP报文，其中nw_proto=1表示IP报文的payload是icmp报文，icmp_code=0，icmp_type=8表示匹配icmp的request报文，nw_dst=10.10.10.197表示匹配目的端为10.10.10.197的icmp请求报文。成功匹配后执行drop操作。 table 0, entry 2: 匹配从vnet4网卡发往目的IP为10.10.10.195的icmp请求报文，原理同上，成功匹配后执行drop操作。 table 1, entry 0: 匹配从vnet4网卡发往目的IP为10.10.10.196的icmp请求报文，原理同上，成功匹配后执行normal操作。 虚拟机1：[root@s1_vm1 ~]# ip addr show ens73: ens7: mtu 1500 qdisc fq_codel state UP group default qlen 1000link/ether 24:42:53:21:52:4e brd ff:ff:ff:ff:ff:ffinet 10.10.10.196/24 brd 10.10.10.255 scope global noprefixroute ens7 valid_lft forever preferred_lft forever虚拟机2：[root@s1_vm2 ~]# ip addr show ens73: ens7: mtu 1500 qdisc fq_codel state UP group default qlen 1000link/ether 24:42:53:21:50:4e brd ff:ff:ff:ff:ff:ffinet 10.10.10.197/24 brd 10.10.10.255 scope global noprefixroute ens7 valid_lft forever preferred_lft forever主机：[root@Hyman_server1 qemu]# ovs-ofctl show vsOFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:00002644428c474en_tables:254, n_buffers:0capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATSOFPST_PORT_DESC reply (OF1.3) (xid=0x3): 2(vnet2): addr:fe:42:53:21:52:4e config: 0 state:LIVE current:10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 3(vnet4): addr:fe:42:53:21:50:4e config: 0 state:LIVE current:10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max LOCAL(vs): addr:26:44:42:8c:47:4e config: 0 state:LIVE speed: 0 Mbps now, 0 Mbps maxOFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x9): frags=normal miss_send_len=0[root@Hyman_server1 qemu]# ovs-vsctl showf1011f20-73a8-44f1-979e-bc4fd82a106fBridge vsPort "vnet2"Interface "vnet2"Port "vnet4"Interface "vnet4"Port vsInterface vstype: internalovs_version: "2.11.0" [root@Hyman_server1 qemu]# ovs-ofctldel-flows vs[root@Hyman_server1 qemu]# ovs-ofctldump-flows vs[root@Hyman_server1 qemu]# ovs-ofctl add-flow vs "priority=0,table=0,actions=NORMAL"[root@Hyman_server1 qemu]# ovs-ofctl add-flow vs "priority=1,table=0,dl_type=0x800,nw_proto=1,icmp_code=0,icmp_type=8,nw_dst=10.10.10.197,actions=drop"[root@Hyman_server1 qemu]# ovs-ofctl add-flow vs "priority=1,table=0,in_port=3,dl_type=0x800,nw_proto=1,icmp_code=0,icmp_type=8,nw_dst=10.10.10.195,actions=drop"[root@Hyman_server1 qemu]# ovs-ofctl add-flow vs "priority=0,table=1,in_port=3,dl_type=0x800,nw_proto=1,icmp_code=0,icmp_type=8,nw_dst=10.10.10.196,actions=normal"[root@Hyman_server1 qemu]# ovs-ofctldump-flows vscookie=0x0, duration=1094.045s, table=0, n_packets=8, n_bytes=784, priority=1,icmp,nw_dst=10.10.10.197,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=325.604s, table=0, n_packets=3, n_bytes=294, priority=1,icmp,in_port=vnet4,nw_dst=10.10.10.195,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=1252.963s, table=0, n_packets=85, n_bytes=6454, priority=0 actions=NORMAL cookie=0x0, duration=369.321s, table=1, n_packets=0, n_bytes=0, priority=0,icmp,in_port=vnet4,nw_dst=10.10.10.196,icmp_type=8,icmp_code=0 actions=NORMAL根据流表配置，我们可以知道，vm1所有发往vm2（IP 为10.10.10.197）的icmp的报文会被丢弃，但发往主机（IP为10.10.10.195）的icmp报文可以正常接受。vm2发往主机的icmp报文会被丢弃，但发往vm2的icmp包围可以被正常处理。检查如下： 首先查看主机侧流表的统计信息： [root@Hyman_server1 qemu]# ovs-ofctldump-flows vscookie=0x0, duration=2058.484s, table=0, n_packets=8, n_bytes=784, priority=1,icmp,nw_dst=10.10.10.197,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=1290.043s, table=0, n_packets=3, n_bytes=294, priority=1,icmp,in_port=vnet4,nw_dst=10.10.10.195,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=2217.402s, table=0, n_packets=117, n_bytes=8862, priority=0 actions=NORMAL cookie=0x0, duration=1333.760s, table=1, n_packets=0, n_bytes=0, priority=0,icmp,in_port=vnet4,nw_dst=10.10.10.196,icmp_type=8,icmp_code=0 actions=NORMAL发往主机的4个icmp报文被接受，主机侧table 0, entry 0报文匹配数增加： 虚侧：[root@s1_vm1 ~]# ping 10.10.10.195 -c 4PING 10.10.10.195 (10.10.10.195) 56(84) bytes of data.64 bytes from 10.10.10.195: icmp_seq=1 ttl=64 time=1.87 ms64 bytes from 10.10.10.195: icmp_seq=2 ttl=64 time=0.250 ms64 bytes from 10.10.10.195: icmp_seq=3 ttl=64 time=0.250 ms64 bytes from 10.10.10.195: icmp_seq=4 ttl=64 time=0.468 ms--- 10.10.10.195 ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 67ms主机侧：[root@Hyman_server1 qemu]# ovs-ofctldump-flows vscookie=0x0, duration=2198.824s, table=0, n_packets=8, n_bytes=784, priority=1,icmp,nw_dst=10.10.10.197,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=1430.383s, table=0, n_packets=3, n_bytes=294, priority=1,icmp,in_port=vnet4,nw_dst=10.10.10.195,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=2357.742s, table=0, n_packets=129, n_bytes=9814, priority=0 actions=NORMAL cookie=0x0, duration=1474.100s, table=1, n_packets=0, n_bytes=0, priority=0,icmp,in_port=vnet4,nw_dst=10.10.10.196,icmp_type=8,icmp_code=0 actions=NORMALvm1发往vm2的4个icmp报文被丢弃，主机侧table 0, entry 0、table 0, entry 1报文匹配数增加： 虚机：[root@s1_vm1 ~]# ping 10.10.10.197 -c 4PING 10.10.10.197 (10.10.10.197) 56(84) bytes of data.--- 10.10.10.197 ping statistics ---4 packets transmitted, 0 received, 100% packet loss, time 65ms主机侧：[root@Hyman_server1 qemu]# ovs-ofctldump-flows vscookie=0x0, duration=2288.083s, table=0, n_packets=12, n_bytes=1176, priority=1,icmp,nw_dst=10.10.10.197,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=1519.642s, table=0, n_packets=3, n_bytes=294, priority=1,icmp,in_port=vnet4,nw_dst=10.10.10.195,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=2447.001s, table=0, n_packets=131, n_bytes=9898, priority=0 actions=NORMAL cookie=0x0, duration=1563.359s, table=1, n_packets=0, n_bytes=0, priority=0,icmp,in_port=vnet4,nw_dst=10.10.10.196,icmp_type=8,icmp_code=0 actions=NORMALvm2发往vm1的4个icmp报文被接受，主机侧table 0, entry 0报文匹配数增加： 虚机：[root@s1_vm2 ~]# ping 10.10.10.196 -c 4PING 10.10.10.196 (10.10.10.196) 56(84) bytes of data.64 bytes from 10.10.10.196: icmp_seq=1 ttl=64 time=0.673 ms64 bytes from 10.10.10.196: icmp_seq=2 ttl=64 time=0.572 ms64 bytes from 10.10.10.196: icmp_seq=3 ttl=64 time=0.542 ms64 bytes from 10.10.10.196: icmp_seq=4 ttl=64 time=0.593 ms--- 10.10.10.196 ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 8ms主机侧：[root@Hyman_server1 qemu]# ovs-ofctldump-flows vs cookie=0x0, duration=2410.358s, table=0, n_packets=12, n_bytes=1176, priority=1,icmp,nw_dst=10.10.10.197,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=1641.917s, table=0, n_packets=3, n_bytes=294, priority=1,icmp,in_port=vnet4,nw_dst=10.10.10.195,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=2569.276s, table=0, n_packets=143, n_bytes=10850, priority=0 actions=NORMAL cookie=0x0, duration=1685.634s, table=1, n_packets=0, n_bytes=0, priority=0,icmp,in_port=vnet4,nw_dst=10.10.10.196,icmp_type=8,icmp_code=0 actions=NORMALvm2发往主机的4个icmp报文被丢弃，主机侧table 0, entry 0、table 0, entry 2报文匹配数增加： 虚机侧：[root@s1_vm2 ~]# ping 10.10.10.195 -c 4PING 10.10.10.195 (10.10.10.195) 56(84) bytes of data.--- 10.10.10.195 ping statistics ---4 packets transmitted, 0 received, 100% packet loss, time 112ms主机侧：[root@Hyman_server1 qemu]# ovs-ofctldump-flows vscookie=0x0, duration=2605.175s, table=0, n_packets=12, n_bytes=1176, priority=1,icmp,nw_dst=10.10.10.197,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=1836.734s, table=0, n_packets=7, n_bytes=686, priority=1,icmp,in_port=vnet4,nw_dst=10.10.10.195,icmp_type=8,icmp_code=0 actions=drop cookie=0x0, duration=2764.093s, table=0, n_packets=145, n_bytes=10934, priority=0 actions=NORMAL cookie=0x0, duration=1880.451s, table=1, n_packets=0, n_bytes=0, priority=0,icmp,in_port=vnet4,nw_dst=10.10.10.196,icmp_type=8,icmp_code=0 actions=NORMALInstructions 
