摘要

  • OpenFlow 允许交换机在没有 Barrier 的情况下为性能重排部分消息；同一连接上的 Barrier Reply 证明此前消息已完整处理，并已产生相应回复或错误，后续消息才可开始。
  • “完整处理”并不等于“数据包已经发出”。规范明确指出，Packet-Out 即使处理完毕，也可能因拥塞、QoS、端口阻塞或端口无效而在交换机内静默丢失。
  • Nick McKeown 的人物意义在于他与七位合著者及后续社区共同把控制器与转发面之间的边界做成了可编程接口。运维也应尊重这个边界，以排序、状态、命中、出口、路径和结果的独立回执判断成功。

一条正确回复如何伴随一次失败

假设控制器依次发送 FlowMod 和 Barrier Request，随后收到 Barrier Reply。交换机没有违反协议，但业务仍然可能中断：新规则装进了错误的表；匹配掩码写错；更高优先级规则抢先命中；group 选择了另一 bucket；meter 丢弃了流量；出口端口处于阻塞状态；或者第一跳之后的设备发生故障。

甚至控制器还可能忽略了此前返回的错误，只把 Barrier Reply 记成成功。Barrier 的职责是建立顺序界线，不是替自动化解释界线内的每一条结果。

OpenFlow 1.3.5 对这件事写得很具体。若无 Barrier，交换机可以为提高性能而重排消息。在一条连接上，Barrier Request 之前的消息必须完整处理，包括由它们产生的回复或错误；随后处理 Barrier 并返回 Barrier Reply；之后的消息才可开始。规范举出的依赖关系包括：先建 group，再安装引用它的 flow；先修改端口，再用 Packet-Out 走该端口；先装规则，再把一个 Packet-Out 送入流表。

因此，它是一张控制通道的排序回执。它不是跨设备事务，也没有观察任何真实数据包。

McKeown 所参与建立的边界

2008 年的 OpenFlow 论文由 Nick McKeown、Tom Anderson、Hari Balakrishnan、Guru Parulkar、Larry Peterson、Jennifer Rexford、Scott Shenker 和 Jonathan Turner 共同署名。论文提出的交换并不神秘：控制器能够为真实交换机增删流表项，后续数据包仍由高速转发面处理。Amy-OSPF 示例中，软件决定路径，并沿途给交换机写入表项。

McKeown 应被称为 OpenFlow 与软件定义网络的共同发起者，而不是唯一发明人；后来的 Barrier 语义也属于部署者、厂商、研究者和 Open Networking Foundation 共同演化的规范。本文选择他，不是为了塑造个人英雄，而是因为这套架构把“作出决定”和“执行转发”分开得足够清楚，让每一种回执的含义可以被精确定义。

2014 年的部署回顾指出，实际实验反馈推动 OpenFlow 0.9 引入 Barrier 命令。它同时记录了流表安装时延波动、交换机 CPU 性能不足、带内控制难题，以及把控制通道踪迹与 RTT、CPU、安装速率和应用测量结合起来的排障方式。这段历史说明：Barrier 是分层观测中的一个工具，从来不是把其他证据删掉的理由。

“处理完毕”的终点还在交换机里面

OpenFlow 1.3.5 给出了最关键的限制：Packet-Out 被完整处理，并不保证数据包离开交换机。拥塞、QoS、阻塞端口或无效端口都可能在 OpenFlow 处理之后造成静默丢包。发往控制器的数据包也可能因拥塞或 policing 消失，而没有预期的 Packet-In。

流表项本身也是一个管线对象，不是一条端到端路径的判决书。它包含匹配字段、优先级、计数器、指令、超时和 cookie。处理从 table 0 开始，可能继续经过多张表；每张表由优先级最高的匹配项获胜。指令可以修改 metadata 和 action set，也可调用 group、meter 以及出口处理。

所以，在 Barrier 后回读到目标 cookie，比只看到 Reply 更强；但这仍不能证明生产数据包命中了它。目标计数器上升，比状态回读更强；但它只能证明本地命中。端口计数器上升，又向前一步；仍不能证明下一跳或应用收到了内容。

连接范围同样不能被扩大。规范明确说不同 OpenFlow 连接之间没有同步。若依赖操作走辅助连接，而 Barrier 走主连接，主连接上的 Reply 不能为辅助连接盖章。控制器重连以后，还应重新确认角色、连接代次及交换机保留的真实状态。

一套合规测试中的两种真相

ONF 的 OpenFlow 1.3.4 Basic Single Table 合规测试把差异保留得很干净。Barrier 测试在一条控制连接上添加最多 10,000 条流，再删除它们并发送 Barrier Request；只有请求的 Flow-Removed 通知全部出现之后，才应收到 Barrier Reply。相邻的 Packet-Out 测试则另用数据面连接，并直接检查数据包是否到达。

两项测试分开，是因为它们回答不同问题。把两盏灯放在同一页面上，不会让第一项突然拥有第二项的语义。

OpenFlow 1.5.1 的 bundle 又加强了另一层证据。多个修改可以先暂存再一起提交；若提交阶段某项失败，整组不应应用。但 bundle 支持是可选能力，也受设备限制。成功提交比零散 FlowMod 提供更强的配置原子性，却仍未证明哪一个生产报文命中了哪条规则。

VeriFlow 则把验证层放在控制器与设备之间，根据规则变化检查全网不变量。它的出发点正是：不能只信任复杂控制器代码。模型可以提前发现环路、黑洞或策略冲突，但模型不是链路上的探头，也不是接收应用的日志。它是独立的一层证据，不是物理交付的替身。

从意图到结果的八张回执

一次可审计的发布至少应保留以下链条：

  1. 意图回执：版本化的策略和期望规则集。
  2. 传输回执：正确的 Datapath ID、控制器角色和连接。
  3. 排序回执：同一连接上的 Barrier Reply，并已核对此前回复与错误。
  4. 状态回执：Fence 后回读表、优先级、掩码、cookie、group、meter 和端口。
  5. 命中回执：具有代表性的受控数据包改变预期流与表计数器。
  6. 出口回执：端口或队列证据显示从指定接口发出，且无本地丢弃条件。
  7. 路径回执：下游观测或主动探测确认实际路径。
  8. 结果回执：终端或应用记录到目标事务。

这些证据还必须用共同身份连接起来：变更版本、交换机、连接代次、OpenFlow 事务标识、cookie、探测报头和时间窗口。否则，一次旧状态回读可能与另一次新探测被拼成一条从未真实存在的成功链。

来源