企业官网建设流程全解析

简介：OpenFlow协议1.3.0中文完整版PDF，面向SDN学习者、网络工程师与控制器开发人员，帮助读者系统掌握控制器与OpenFlow交换机之间的通信规范。文档共91页，围绕流表、组表、保留端口与逻辑端口等核心组件展开，逐层讲解匹配字段、优先级、计数器与指令集的构成，并说明数据包从首表匹配、漏表处理到流水线终止的完整流程。组表部分重点阐述多路径转发、负载均衡与快速重路由等高级策略，以及行动存储段如何被多个流表项复用；端口章节则区分物理端口、逻辑端口与保留端口，并解释泛洪、上送控制器等通用转发行为。资源包为1个PDF文件，大小约1.52MB，单文件结构便于检索与离线查阅。目前已有535人学习下载，适合需要对照协议原文理解OpenFlow 1.3.0语义、设计实验或排查流表配置问题的读者参考。

1. 从一份 91 页的 PDF 说起：OpenFlow 1.3.0 到底解决了什么问题

如果你手头正在跑 OVS、ONOS、Ryu 或者 P4 的入门实验，大概率绕不开一份文档——OpenFlow 协议 1.3.0 的完整中文版。它不是什么教程，也不是什么入门指南，而是一份交换机行为规范：规定了一台 OpenFlow 交换机必须怎么匹配、怎么转发、怎么和控制器对话。换句话说，控制器写出来的流表能不能生效、组表能不能做负载均衡、table-miss 到底丢包还是上送控制器，答案全在这份文档里。它适合三类人：正在做 SDN 实验但被流表行为搞懵的工程师、需要对着协议字段写控制器代码的开发者、以及想搞清楚 OpenFlow 1.0 到 1.3 到底差在哪的运维。91 页不算厚，但信息密度极高，尤其是流水线、行动集、组表这几块，翻车的人不在少数。下面我按自己拆文档的顺序，把这份 PDF 里真正能落地的部分捋一遍。

2. 流表、流水线与 table-miss：把匹配流程拆成可复现的步骤

2.1 流表项的五元组结构与优先级匹配

OpenFlow 1.3.0 的流表项不是简单的“匹配+动作”，它由五部分组成：匹配字段、优先级、计数器、指令集、超时与 cookie。匹配字段覆盖入端口、以太网头、IP 头、TCP/UDP 端口，甚至包括前一张表传下来的元数据（metadata）。优先级决定匹配顺序，数值越大越优先。这里有个容易被忽略的点：匹配字段和优先级共同确定唯一流表项，如果两条流表项匹配字段相同、优先级也相同，协议里明确说这是未定义行为——交换机选哪条都行。所以控制器下发流表时，要么保证优先级不重复，要么在流表项里设置OFPFF_CHECK_OVERLAP标志让交换机帮你查重。

匹配流程从流表 0 开始。数据包进入交换机后，提取匹配字段，在流表 0 里按优先级从高到低找第一条匹配的流表项。找到就执行它的指令集；如果指令里有 Goto-Table，就跳到指定表继续匹配。注意，Goto 只能往表号更大的表跳，不能回退。如果某条流表项的指令集里没有 Goto，流水线就在这张表停止，数据包按行动集处理。

提示：很多初学者以为流表是“查一次就完”，实际上 OpenFlow 1.3 是多级流水线，数据包可能经过好几张表才被转发出去。

2.2 table-miss 的三种处理方式与配置差异

如果数据包在某张流表里没有匹配到任何流表项，这就是 table-miss。协议规定每张流表必须支持 table-miss 流表项，它的匹配字段全通配、优先级为 0。table-miss 的处理方式有三种：丢弃、上送控制器、或者 Goto 到后续表。默认情况下，如果控制器没有下发 table-miss 流表项，数据包直接被丢弃。

这里有个实操中经常踩的坑：table-miss 流表项必须至少支持两种能力——通过 CONTROLLER 保留端口上送控制器，以及用 Clear-Actions 指令丢弃数据包。但“Goto 到后续表”这个能力是“鼓励支持”而非强制。所以如果你在 OVS 上跑得好好的配置，换到某些硬件交换机上可能就不行了，因为它的 table-miss 不支持 Goto。

配置 table-miss 的典型命令如下（以 OVS 为例）：

# 添加 table-miss 流表项，将未匹配数据包上送控制器 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=0, actions=controller" # 或者丢弃 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=0, actions=drop" # 或者跳到表 1 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=0, actions=goto_table:1"

参数说明：-O OpenFlow13指定协议版本，table=0表示流表 0，priority=0是最低优先级，actions=后面跟指令。注意controller后面可以跟参数，比如controller:max_len=128限制上送控制器的数据包字节数，避免大包占满控制通道。

2.3 流表项超时机制与删除通知

流表项有两种删除方式：控制器主动删除，或者交换机根据超时机制自动删除。每个流表项有两个超时字段：idle_timeout和hard_timeout。idle_timeout表示如果在这段时间内没有数据包匹配，就删除；hard_timeout表示不管有没有匹配，到时间就删除。两者可以同时设置，谁先到就按谁删。

删除时，如果流表项设置了OFPFF_SEND_FLOW_REM标志，交换机会发送 Flow Removed 消息给控制器，里面包含完整的流表项描述、删除原因（超时还是主动删除）、持续时间和统计数据。这个机制在做流量监控时非常有用，但要注意：Flow Removed 消息是异步的，控制器需要单独处理，不能指望它和某个请求一一对应。

# 添加一条带超时的流表项，并设置删除通知 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=100, ip, nw_dst=10.0.0.1, \ idle_timeout=30, hard_timeout=120, \ flags=send_flow_rem, actions=output:2"

参数说明：idle_timeout=30表示 30 秒无匹配就删除，hard_timeout=120表示最多存活 120 秒，flags=send_flow_rem开启删除通知。实际部署时，idle_timeout设得太短会导致流表频繁抖动，设得太长又起不到老化作用，一般根据业务流量特征来调，常见范围是 30 到 300 秒。

3. 组表、行动集与计量：多路径转发的落地细节

3.1 四种组类型的选型与配置

组表是 OpenFlow 1.3.0 相比 1.0 最大的增强之一。它把一组行动存储段组织在一起，流表项可以通过 Group 行动指向一个组，实现多播、负载均衡、快速重路由等。协议定义了四种组类型：

all组最常用，比如把数据包复制到多个端口。注意一个细节：如果某个存储段明确指向入端口，这个复制包会被丢弃。如果控制器希望数据包从入端口转发出去，必须额外加一个指向OFPP_IN_PORT的存储段。

select组用于负载均衡，交换机内部用哈希或轮询选一个存储段。哈希因子可以是五元组、入端口等，具体实现由交换机决定。fast failover组则依赖端口或组的有效性状态，第一个有效的存储段被执行，不需要控制器介入就能切换路径。

# 创建一个 all 组，组号 1，包含两个输出端口 ovs-ofctl -O OpenFlow13 add-group br0 \ "group_id=1, type=all, \ bucket=output:2, bucket=output:3" # 创建 select 组，组号 2，两个桶带权重 ovs-ofctl -O OpenFlow13 add-group br0 \ "group_id=2, type=select, \ bucket=weight:50, output:2, \ bucket=weight:50, output:3" # 流表项指向组 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=100, ip, nw_dst=10.0.0.0/24, actions=group:1"

参数说明：group_id是 32 位无符号整数，type指定组类型，bucket定义一个行动存储段。weight只在 select 组里有效，表示权重。注意 OVS 对 select 组的哈希算法默认基于五元组，可以通过ovs-ofctl的--sort参数查看实际分布。

3.2 行动集的执行顺序与常见误用

行动集和行动列表是两个容易混淆的概念。行动集是数据包级别的，在流水线处理过程中逐步累积，当流水线停止时统一执行。行动列表是 Apply-Actions 指令的一部分，立即执行，执行完流水线继续。

行动集里的行动有严格的执行顺序，协议规定如下：copy TTL inwards、pop、push-MPLS、push-PBB、push-VLAN、copy TTL outwards、decrement TTL、set、qos、group、output。这个顺序是固定的，不管行动以什么顺序加入行动集。如果行动集里同时有 group 和 output，group 优先，output 被忽略。如果两者都没有，数据包被丢弃。

常见误用：有人想用行动集实现“先改 MAC 再转发”，于是写了set_field和output，结果发现set_field确实在output之前执行，没问题。但如果想“先压 VLAN 再改 VLAN ID”，就要注意 push-VLAN 在 set 之前执行，所以 set VLAN ID 会作用到新压入的 VLAN 头上，这是符合预期的。但如果想“先改 VLAN ID 再压 VLAN”，行动集做不到，因为顺序固定，必须用 Apply-Actions 行动列表。

# 行动集方式：set_field 在 output 之前执行 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=100, ip, nw_dst=10.0.0.1, \ actions=set_field:00:11:22:33:44:55->eth_dst, output:2" # 行动列表方式：按列表顺序执行 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=100, ip, nw_dst=10.0.0.1, \ actions=set_field:00:11:22:33:44:55->eth_dst, output:2"

这两条命令在 OVS 里看起来一样，但底层处理不同。第一条是 Write-Actions 加入行动集，第二条是 Apply-Actions 立即执行。对于大多数场景，两者效果相同，但在多表流水线里，行动集可以跨表累积，行动列表只在当前表生效。

3.3 计量表与 QoS 限速的配合

计量表（Meter Table）是 OpenFlow 1.3.0 引入的另一个重要特性，用于测量和控制数据包速率。每个计量表项有一个计量器 ID 和多个计量带（Meter Band）。计量带指定速率和处理方式，当测量速率超过配置速率时，计量带被触发。协议定义了两种带类型：drop（丢弃）和 dscp remark（修改 DSCP 字段）。

计量器直接挂在流表项的指令集里，而不是端口队列上。这意味着你可以对任意流做限速，粒度比端口队列更细。比如，你可以对某个 IP 的流量限速 10Mbps，同时对另一个 IP 限速 100Mbps，互不影响。

# 创建计量器，ID 为 1，速率 1000kbps，超过则丢弃 ovs-ofctl -O OpenFlow13 add-meter br0 \ "meter=1, kbps, band=type=drop, rate=1000" # 流表项引用计量器 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=100, ip, nw_dst=10.0.0.1, \ meter:1, actions=output:2"

参数说明：meter=1是计量器 ID，kbps表示速率单位，band=type=drop, rate=1000表示超过 1000kbps 就丢包。注意 OVS 对计量表的支持有限，某些版本只支持 drop 类型，dscp remark 需要硬件支持。实际部署前建议先用ovs-ofctl dump-meters确认交换机能力。

4. 避坑与排查：OpenFlow 1.3.0 实操中的五个血泪教训

4.1 流表项不生效，但 dump 能看到

现象：用ovs-ofctl add-flow下发流表，dump-flows也能看到，但数据包就是不按流表走。

原因：最常见的是协议版本不匹配。OVS 默认可能用 OpenFlow 1.0，而你下发的流表是 1.3 格式，字段名和指令都不一样。另一个原因是流表项优先级被其他表项覆盖，或者 table-miss 把包提前上送控制器了。

解决：所有ovs-ofctl命令都加-O OpenFlow13，并且用ovs-ofctl -O OpenFlow13 dump-flows br0确认流表项实际生效的版本。如果还是不行，检查是否有更高优先级的流表项匹配了同样的数据包。

4.2 组表创建成功但转发异常

现象：add-group返回成功，流表项也指向了组，但数据包只从一个端口出去，或者直接被丢。

原因：all组里如果某个 bucket 指向入端口，那个复制包会被丢弃，这是协议规定的。另外，select组的哈希算法依赖交换机实现，OVS 默认基于五元组，如果流量五元组相同，永远选同一个桶。

解决：检查组表配置，确保没有意外指向入端口。对于select组，如果要做负载均衡，确保流量五元组有差异，或者改用all组配合其他机制。用ovs-ofctl -O OpenFlow13 dump-groups br0查看组表实际内容。

4.3 table-miss 上送控制器的包太多

现象：控制器 CPU 跑满，抓包发现大量 Packet-In 消息。

原因：table-miss 流表项把未匹配数据包全部上送控制器，如果网络里有大量扫描流量或新流，控制器会被淹没。

解决：在 table-miss 之前加一条高优先级的流表项，把已知的、不需要控制器处理的流量直接转发或丢弃。或者用controller:max_len=128限制上送包的长度，减少带宽占用。更彻底的做法是用OFPC_FRAG_REASM标志让交换机重组分片，避免分片包逐个上送。

4.4 流表项超时后 Flow Removed 消息丢失

现象：设置了send_flow_rem标志，但控制器收不到 Flow Removed 消息。

原因：Flow Removed 是异步消息，如果控制器没有正确监听异步消息通道，或者 OpenFlow 通道断开了，消息就丢了。另外，某些交换机实现只在流表项被删除时发送一次，如果控制器当时不在线，不会重发。

解决：确保控制器正确注册了异步消息处理函数。对于关键流表项，不要只依赖 Flow Removed，可以定期用Read-State消息主动查询流统计信息。在 OVS 里，可以用ovs-ofctl -O OpenFlow13 dump-flows br0查看流表项的duration和idle_age字段。

4.5 计量表限速不准确

现象：配置了 1000kbps 的限速，实际流量跑到 1500kbps 才被丢包。

原因：计量表的速率测量是滑动窗口，不是精确的令牌桶。OVS 的计量表实现基于 Linux 内核的 token bucket，窗口大小和突发容忍度会影响精度。另外，如果流表项没有正确引用计量器，限速根本不生效。

解决：用ovs-ofctl -O OpenFlow13 dump-meters br0确认计量器状态。对于精度要求高的场景，考虑用端口队列（Queue）替代计量表，或者结合两者使用。计量表的rate参数建议设置为目标速率的 90% 左右，留出突发余量。

5. 从协议文档到生产配置：一个多表流水线的完整验证方法

把 OpenFlow 1.3.0 的协议文档读透之后，真正的挑战是怎么验证你的配置符合协议语义。我一般会用一个最小化的多表流水线做验证：表 0 做端口分类，表 1 做 ACL，表 2 做转发。这样既能覆盖 Goto 指令，又能测试 table-miss 和行动集。

先建一个简单的拓扑：两台主机接在 OVS 上，控制器用 Ryu 或 ONOS。然后按下面的步骤下发流表：

# 表 0：从端口 1 进来的包跳到表 1 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=0, priority=100, in_port=1, actions=goto_table:1" # 表 1：允许 IP 流量跳到表 2，其他丢弃 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=1, priority=100, ip, actions=goto_table:2" ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=1, priority=0, actions=drop" # 表 2：修改目的 MAC 并转发到端口 2 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=2, priority=100, ip, nw_dst=10.0.0.2, \ actions=set_field:00:11:22:33:44:55->eth_dst, output:2" # 表 2 的 table-miss：上送控制器 ovs-ofctl -O OpenFlow13 add-flow br0 \ "table=2, priority=0, actions=controller"

下发完之后，用ping测试连通性，同时用ovs-ofctl -O OpenFlow13 dump-flows br0观察每条流表项的n_packets计数器。如果表 0 的计数器在涨，表 1 不涨，说明 Goto 没生效，检查表号是否递增。如果表 2 的 set_field 没生效，检查行动集顺序，确认 set 在 output 之前执行。

验证组表的时候，我会用all组做多播测试：一台主机发包，两台主机收包。如果只有一台收到，检查组表 bucket 是否指向了正确的端口，以及是否有 bucket 意外指向了入端口。验证计量表的时候，用iperf打流，同时用ovs-ofctl dump-meters观察band的触发次数。

注意：OVS 的dump-flows输出里，n_packets和n_bytes是累计值，不会自动清零。如果要看某个时间段的流量，需要先记录基线，再做差值。

从那以后我每次上线新的流表配置，都强制走一遍“dump-flows 确认 + 计数器观察 + 抓包验证”三步。协议文档里的每一句话，落到生产环境里都可能是一个坑，但只要按流水线顺序逐表排查，大部分问题都能定位到具体的表项和指令。希望帮到你。

本文还有配套的精品资源，点击获取