3. OpenFlow流表与流水线实战

OpenFlow 1.3 之后，交换机不再只有一张流表，而是支持多级流表（Multiple Tables）组成的流水线（Pipeline）。流水线让转发逻辑可以像程序一样被拆解：第一张表做粗粒度分类，后续表做精细匹配、改写或转发决策。理解流水线的关键，是掌握四个机制：多级流表、table-miss 处理、元数据（metadata）传递、goto-table 指令。本节以 Open vSwitch（OVS）为验证平台，设计一个两级流表的小型实验，观察报文如何在表间跳转。

一、流水线的结构

每张流表由若干流表项（flow entry）组成，每个流表项包含三部分：匹配字段（match fields）、优先级（priority）、指令集（instructions）。报文进入交换机后，从 table 0 开始匹配。匹配规则是：在所有流表项中选出优先级最高且匹配成功的那一条，执行其指令。指令可以包括：apply-actions（立即执行动作）、write-actions（写入动作集，稍后统一执行）、write-metadata（写元数据）、goto-table（跳转到指定表）、drop（丢弃）。

流水线中，报文只能沿表号递增方向跳转，不能回退。这保证了处理过程是单向的、可预测的。每张表可以有自己的 table-miss 流表项，用于处理“没有任何流表项匹配”的报文。若某张表没有 table-miss 项且报文未匹配，默认行为是丢弃。

二、table-miss 处理

table-miss 是流水线中最容易被忽视、却最影响行为的机制。当报文在某张表中没有任何流表项匹配时，交换机会查找该表的 table-miss 流表项。table-miss 项的特征是：匹配字段为空（match all）、优先级为 0。它的指令决定了未匹配报文的命运：

• drop：直接丢弃，适合安全隔离场景。
• output:CONTROLLER：上送控制器，由控制器决定后续处理，这是最常见的做法。
• goto-table:N：跳到下一张表继续处理，适合“默认走后续流水线”的设计。

在 OVS 中，如果某张表没有配置 table-miss 项，默认行为是丢弃。因此，设计流水线时，每张表都应显式配置 table-miss，避免报文被静默丢弃而难以排查。

三、元数据传递

metadata 是一个 64 位的寄存器，用于在流表之间传递信息。它不参与报文本身的修改，只存在于交换机内部的处理上下文中。典型用法是：table 0 根据入端口、VLAN 等字段判断报文类别，把类别编号写入 metadata；table 1 直接匹配 metadata，执行对应的转发或改写动作。这样避免了在每张表中重复匹配相同字段，也降低了流表项数量。

metadata 的写入使用 write-metadata 指令，读取则在匹配字段中写 metadata=值/掩码。注意：metadata 只在同一报文处理过程中有效，报文离开交换机后即消失。

四、goto-table 指令

goto-table 是流水线跳转的核心指令。它把报文交给指定表继续处理，表号必须大于当前表号。与 apply-actions 不同，goto-table 不会立即执行动作，而是把控制权交给下一张表。如果同一流表项中既有 write-actions 又有 goto-table，动作集会随报文一起传递，直到流水线结束或遇到 apply-actions 才执行。

五、OVS 验证实验

下面用 OVS 搭建一个最小验证环境。假设已安装 Open vSwitch，使用 ovs-vsctl 创建网桥 br0，并添加两个端口 veth1、veth2。实验目标是：从 veth1 进入的报文，经 table 0 分类后写入 metadata，再由 table 1 根据 metadata 转发到 veth2。

# 创建网桥与端口
ovs-vsctl add-br br0
ovs-vsctl add-port br0 veth1
ovs-vsctl add-port br0 veth2

# 设置 OpenFlow 1.3
ovs-vsctl set bridge br0 protocols=OpenFlow13

# 查看端口号
ovs-ofctl -O OpenFlow13 show br0

假设 veth1 对应 port 1，veth2 对应 port 2。接下来下发两级流表。table 0 的规则：匹配 in_port=1，写入 metadata=0x1，跳转到 table 1；table-miss 上送控制器。table 1 的规则：匹配 metadata=0x1，输出到 port 2；table-miss 丢弃。

# Table 0：分类并写 metadata
ovs-ofctl -O OpenFlow13 add-flow br0 \
  "table=0,priority=100,in_port=1,actions=write_metadata:0x1,goto_table:1"

# Table 0：table-miss 上送控制器
ovs-ofctl -O OpenFlow13 add-flow br0 \
  "table=0,priority=0,actions=output:CONTROLLER"

# Table 1：根据 metadata 转发
ovs-ofctl -O OpenFlow13 add-flow br0 \
  "table=1,priority=200,metadata=0x1,actions=output:2"

# Table 1：table-miss 丢弃
ovs-ofctl -O OpenFlow13 add-flow br0 \
  "table=1,priority=0,actions=drop"

下发后，用 ovs-ofctl dump-flows 查看流表，确认每条流表项的 table、priority、match 和 instructions 是否符合预期。然后从 veth1 发送测试报文（例如用 ping 或 scapy 构造），观察 veth2 是否收到。同时可以用 ovs-ofctl dump-flows br0 查看 n_packets 计数是否增长，判断流表项是否被命中。

六、结果判读与常见问题

如果 veth2 没有收到报文，按以下顺序排查：第一，确认 table 0 的 in_port 匹配是否正确，可用 ovs-appctl ofproto/trace 模拟报文路径；第二，确认 table 1 的 metadata 匹配值是否与写入值一致，注意十六进制格式；第三，确认 table-miss 是否误将报文丢弃；第四，检查端口号是否与预期一致。OVS 提供的 ofproto/trace 是排查流水线问题最有效的工具，它能逐表打印匹配结果和执行的指令。

# 模拟从 port 1 进入的报文
ovs-appctl ofproto/trace br0 in_port=1,eth_dst=00:00:00:00:00:01

输出会显示报文在 table 0 匹配到哪条流表项、写入的 metadata 值、跳转到 table 1 后匹配到哪条流表项、最终执行什么动作。通过对比 trace 输出与设计预期，可以快速定位是匹配字段写错、优先级冲突还是 table-miss 配置不当。

通过本节的两级流水线实验，可以直观看到报文如何从 table 0 分类、写入 metadata、跳转到 table 1、最终转发到目标端口。掌握这套机制后，后续可以扩展到更复杂的场景，例如多租户隔离、ACL 与转发分离、服务链编排等。