一、概述
1.1 Why Open vSwitch（1）
| Why Open vSwitch... Open vSwitch's forwarding path (the in-kernel datapath) is designed to be amenable to "offloading" packet processing to hardware chipsets, whether housed in a classic hardware switch chassis or in an end-host NIC. This allows for the Open vSwitch control path to be able to both control a pure software implementation or a hardware switch. |
1. Forwarding path is in-kernel datapath
"Open vSwitch's forwarding path (the in-kernel datapath)..."
OVS 的数据包转发路径是在 Linux 内核模块中实现的，性能高、延迟低。
这部分处理数据包的核心逻辑，比如流表匹配、封装/解封装、转发等。
2. Amenable to offloading
"...is designed to be amenable to offloading packet processing to hardware chipsets..."
设计目标之一是便于“卸载”数据包处理到硬件上。
所谓“offloading”，即把数据包的匹配与转发操作，从 CPU/内核转交给：
硬件交换芯片（ASIC）
智能网卡（SmartNIC、DPDK NIC）
可编程网卡（如 NVIDIA BlueField, Intel IPU）
这种架构可以大幅提升性能、降低延迟，尤其适合数据中心场景。
3. Works in hardware switches or SmartNICs
"...whether housed in a classic hardware switch chassis or in an end-host NIC."
这种“卸载”不仅适用于传统的硬件交换机（如 Broadcom 芯片），
也可以应用于 宿主机中的智能网卡（NIC）。
简而言之，OVS 支持软硬协同：
软件层灵活控制（OpenFlow、OVN、VXLAN、QoS…）
数据包处理可以由硬件接管（如 flow table 下沉到芯片），（注：这个flow table实际可以理解为硬件转发表项，不是用户态的openflow table，而是下发到内核的转发表了。）
4. Control path stays the same
"This allows for the Open vSwitch control path to be able to both control a pure software implementation or a hardware switch."
无论是 软件版 OVS（纯用户态 + 内核态）还是 硬件交换机（比如用 ASIC 实现转发），
它们都可以被同一套 OVS 控制逻辑所控制（即“控制路径”一致）：
统一的 API（OVSDB / OpenFlow / OVN）
统一的配置工具（如
ovs-vsctl,ovs-ofctl）✅ 总结一句话：
Open vSwitch 的架构实现了“控制逻辑统一 + 数据面可卸载”的设计目标，既适用于软件定义网络，也适用于硬件加速环境。
🧩 延伸理解：软件 + 硬件协同的 OVS 应用场景
场景 控制路径（控制层） 转发路径（数据面） 普通虚拟交换机（如 OpenStack） ovs-vswitchd + ovsdb-server 内核模块 datapath（system） 高性能 DP/DPDK 场景 同上 用户态 netdev + DPDK SmartNIC 加速（如 Mellanox） 同上 NIC 上的 ASIC/Switch 芯片 白盒交换机（如 OCP 硬件） 同上 Broadcom / Intel ASIC
1.2 Why Open vSwitch（2）
| ...Why Open vSwitch The advantage of hardware integration is not only performance within virtualized environments. If physical switches also expose the Open vSwitch control abstractions, both bare-metal and virtualized hosting environments can be managed using the same mechanism for automated network control. |
这段话讲的是 Open vSwitch 与硬件集成的优势 不只是提升性能，还有更大的架构价值，下面是逐句解读：
The advantage of hardware integration is not only performance within virtualized environments.
✅ 解释：
把 OVS 的数据面卸载到硬件（如 ASIC、SmartNIC）的一个直接好处是性能提升（比如更高的吞吐、更低延迟）；
但这不是唯一的优势；
真正重要的是——控制的一致性与自动化能力。
If physical switches also expose the Open vSwitch control abstractions,
✅ 解释：
假如物理交换机（例如白盒交换机、可编程交换机）也支持 Open vSwitch 的控制接口（抽象），比如：
OVSDB 接口
OpenFlow 流表管理
OVN northbound/southbound API
就意味着你可以像操作一个软件交换机一样操作物理设备。
both bare-metal and virtualized hosting environments can be managed using the same mechanism for automated network control.
✅ 解释：
不管你的服务器是：
虚拟化环境（如 KVM + OpenStack）
物理裸金属环境（bare-metal，如 Kubernetes 节点、数据库主机等）
只要它们连接的网络设备都支持 OVS 控制抽象，那么就可以使用同一套网络控制系统（SDN 控制器、OVN、Ansible 等）进行自动化编排与管理。
🎯 总结一句话：
通过统一 OVS 控制接口，虚拟交换机与物理交换机都可以纳入同一套自动化网络控制系统，实现全栈网络统一管理。
🧩 举个例子
你用 OVN 做网络控制平面，结合 OVS：
在 OpenStack/KVM 上运行虚拟机，使用
br-int转发；在物理服务器上用裸金属运行 Pod；
在 ToR（Top of Rack）交换机使用支持 OVS/OVN 的白盒交换机（如基于 Broadcom 的设备）；
你可以用 一套 OVN 控制器 对这些不同设备统一下发路由、ACL、隧道规则，无需写两套脚本。
示意图：
+--------------------+ | OVN / SDN | ← 控制路径（统一） +--------------------+ ↓ +------------+ ↓ +------------------+ | Virtual OVS| ← OVSDB → | Hardware Switch | | (br-int) | | (with OVS logic) | +------------+ +------------------+ | | 虚拟机流量 裸金属流量如果你所在的金融行业有裸金属服务器 + 私有云混合部署的场景，这种模式特别适合统一规划二层/三层网络、做多租户隔离、实施集中式防火墙策略等。
1.3 Main Components
| Main Components
|
这张图清晰地展示了 Open vSwitch（OVS）体系结构的主要组件及交互关系。以下是对图中各部分的详细解读：
✅ 图中主要组件说明
组件名称 作用与职责 ovsdb-server 提供数据库支持（OVSDB 协议），管理交换机配置，如端口、桥、接口、QoS 等，通常监听 6632/TCP。ovs-vswitchd OVS 数据面的控制守护进程，处理 OpenFlow 控制、策略执行、流表安装等，通常监听 6633/TCP。OVS Kernel Module OVS 的内核数据转发模块，处理高速报文转发，匹配流表后执行相应动作。 🔁 组件间通信关系
ovs-vswitchd ⇆ ovsdb-server
协议：OVSDB 管理协议（6632/TCP）
用于读取或更新交换机配置，比如添加桥、接口、端口、设置 VLAN、QoS 等。
ovs-vswitchd ⇆ OVS Kernel Module
协议：Netlink（绿色箭头）
用于下发、同步流表，和从内核模块获取流统计等信息。
控制器（Control Cluster）⇆ ovs-vswitchd
协议：OpenFlow（6633/TCP）
控制器可以是 ODL、ONOS、Ryu、Faucet 等，向 OVS 下发流表规则、策略。
控制器 ⇆ ovsdb-server
协议：OVSDB 管理协议（6632/TCP）
控制器可直接管理 OVS 数据库配置（如动态添加桥、端口等），用于 overlay 网络等高级场景。
📌 图中术语补充说明
项目 说明 Off-box 控制器在 OVS 所在机器外部（常见于 SDN 架构） User space 用户空间程序，例如 ovs-vswitchd,ovsdb-serverKernel space 内核态模块，负责高速转发（OVS 的 datapath） 💡 总结一句话
OVS 的控制面（ovs-vswitchd + ovsdb-server）运行在用户态，数据面（kernel module）运行在内核态，控制器可通过 OpenFlow 和 OVSDB 协议进行远程管理和控制。
二、CONFIGURATION DATABASE
2.1 ovsdb-server
| ovsdb-server
|
这段话是对
ovsdb-server的功能和架构特点的描述，我们逐点来解读它的含义：1、什么是
ovsdb-server？“Database that holds switch-level configuration”
ovsdb-server是 Open vSwitch 架构中的 配置数据库服务进程，它使用 OVSDB 协议与其他组件通信，用于存储和管理控制面配置数据。2、存储内容包括：
– Bridge, interface, tunnel definitions
– OVSDB and OpenFlow controller addresses即它存储了以下信息：
所有虚拟交换机（bridges）的定义；
各个 bridge 下面的接口（interfaces）、端口（ports）、隧道（如 VXLAN）；
与 OpenFlow 控制器或 OVSDB 管理端的连接地址；
例如你通过
ovs-vsctl创建的br-int、br-ex都是写入到这个数据库中的。3、数据持久化
“Configuration is stored on disk and survives a reboot”
OVSDB 的配置数据是持久化保存在磁盘上的；
即使主机重启，重启
ovsdb-server和ovs-vswitchd后配置会自动恢复；默认存储路径如
/etc/openvswitch/conf.db。4、自定义数据库（非 SQLite/PostgreSQL）
“Custom database with nice properties:”
OVSDB 是 Open vSwitch 专门为网络配置设计的数据库格式，具备以下优点：
- Value constraints（值约束）
可以对字段定义类型、取值范围；
比如
ofport是整数，name是字符串。- Weak references（弱引用）
类似于外键，可以引用其他表中的对象，但允许目标不存在或延迟创建；
适合网络设备的“先定义接口，后定义 bridge”这种不确定顺序的场景。
- Garbage collection（垃圾回收）
如果一个对象没有被任何其他对象引用（如孤立的接口），数据库会自动清理它；
保持数据库结构整洁。
5、Log-based（日志式结构）
“Fantastic for debugging!”
OVSDB 是追加式存储结构，所有变更操作都会记录在日志中；
这便于回溯故障、调试配置问题，甚至可以用 replay 工具重现问题；
有专门的工具（如
ovsdb-tool) 可用于解析数据库。6、OVSDB 协议通信
“Speaks OVSDB protocol to manager and ovs-vswitchd”
ovsdb-server使用 OVSDB 协议（基于 JSON-RPC） 与：
ovs-vswitchd（用户空间交换机进程）通信，获取配置外部管理器（如 OVN、SDN 控制器）通信，接受配置指令
✅ 总结一句话：
ovsdb-server是 Open vSwitch 的核心配置数据库，专为网络设计，支持结构化约束、持久化存储、日志调试，并通过 OVSDB 协议与控制器或交换进程通信，是整个 SDN 控制面的“存储大脑”。🔧 常见命令回顾：
ovs-vsctl show # 从 ovsdb 读取整体配置
ovs-vsctl add-br br0 # 写入 ovsdb 中添加交换机
ovsdb-tool show-log conf.db # 查看数据库日志结构
ovsdb-client dump # 直接查询数据库内容（调试用）
2.2 Core Tables
| Core Tables
|
这段话讲的是 OVS 的配置数据库（即
ovsdb-server）中的核心表结构，重点强调了Open_vSwitch表的特殊地位。下面是逐句解析：🔹 “Open_vSwitch is the root table”
Open_vSwitch是整个 OVS 配置数据库（ovs-vswitchd.conf.db）的根表（Root Table）
所有配置数据都可以从这张表递归跟踪到其他表；
就像一个入口节点一样，指向所有桥、端口、控制器、镜像等；
这张表永远只会有一行（即
row 0）。🔹 “there is always only a single row”
它代表了当前系统中的唯一实例
这行里存放着全局性的配置项，比如：
主机名（hostname）
OVS 版本
启动的 bridge 列表
当前配置版本（cur_cfg）
🔍 示例命令查看这张表：
ovs-vsctl list Open_vSwitch
输出中你会看到：_uuid : 49984c65-27c7-... bridges : [uuid1, uuid2] cur_cfg : 58 external_ids : {hostname=..., system-id=...}🔹 “The tables here are the ones most commonly used”
该段说明提到的是常用表（核心表），实际数据库中还有很多辅助表，但这里列的是最关键的部分。
常见核心表包括：
表名 描述 Open_vSwitch根表，系统全局配置 Bridge每个虚拟交换机 Port虚拟端口（port，可能包含多个接口） Interface实际的网络设备，比如 tap、vxlan、gre 接口 ControllerOpenFlow 控制器配置 Mirror用于流量镜像（port mirroring） QoS,Queue流量整形、排队策略 Flow_Sample_Collector_SetsFlow/NetFlow 配置 ManagerOVSDB 管理器（远程连接器）配置 🔹 “A full entity-relationship diagram is available in the ovs-vswitchd.conf.db man page.”
如果你想看到完整的实体关系图（表结构 + 外键关系），可以查看手册：
man ovs-vswitchd.conf.db
或者在线文档：OVS schema documentation🧩 总结一句话：
Open_vSwitch是 OVS 配置数据库的根表，是所有配置项的起点，永远只有一行，通过它可以关联到 bridge、interface、controller 等其他表，整个数据库结构类似一棵配置树。
2.3 Debugging the Database
| Debugging the Database
|
这段内容讲的是如何调试和管理 Open vSwitch 配置数据库（即 OVSDB）的常用命令工具，下面是详细解读：
🧰 常用调试工具分为两类：
工具 作用范围 典型用途 ovs-vsctl高层配置接口 配置和查看 OVS 的运行时状态 ovsdb-tool底层数据库文件操作 检查、恢复、回放数据库文件 🔹
ovs-vsctl（控制面配置工具）它其实是对 OVSDB 的高级封装接口，对用户更友好，常用于配置
ovs-vswitchd的各项功能。常用命令解释如下：
命令 说明 ovs-vsctl add-br <bridge>添加一个虚拟交换机（桥） ovs-vsctl list-br列出当前所有桥 ovs-vsctl add-port <bridge> <port>向某个桥添加一个端口（如物理网卡、tap设备、vxlan隧道等） ovs-vsctl list-ports <bridge>列出某个桥下的所有端口 ovs-vsctl get-manager获取当前 OVSDB 管理器地址（用于远程连接） ovs-vsctl get-controller获取当前桥的 OpenFlow 控制器地址 ovs-vsctl list <table>查看某张 OVSDB 表的所有行内容，如： list Interface、list Bridge👉 实质上这些命令读取或修改的是 OVSDB 的配置项。
🔹
ovsdb-tool（数据库底层文件管理工具）用于对 数据库文件本身（如
conf.db） 进行检查、调试、回放、升级等操作。常用命令：
命令 说明 ovsdb-tool show-log [-mmm] <file>显示数据库日志的回放操作，非常适合用于调试数据库内容的变更历史。例如：
ovsdb-tool show-log /etc/openvswitch/conf.db会输出所有写操作。
加-mmm参数可以显示更详细的修改内容。这个工具主要用于：
- 数据库文件损坏时恢复；
- 分析配置变更历史；
- 离线调试配置；
- 数据库版本迁移（如升级 OVS 版本时使用）。
🧩 图示理解（调试流程）：
+----------------+ | ovs-vsctl | ← 人类友好接口 +----------------+ | ↓ +----------------+ | ovsdb-server | ← 运行时数据库服务 +----------------+ | ↓ /etc/openvswitch/conf.db ← 文件实际存储 ↑ +----------------+ | ovsdb-tool | ← 操作底层文件 +----------------+✅ 总结一句话：
ovs-vsctl是用来修改运行中 OVS 配置的高级命令，ovsdb-tool是用来离线调试或检查 OVS 数据库文件的底层工具。配合使用可以帮助你快速定位配置问题、回溯变更、恢复错误。
2.4 ovsdb-tool show-log
| ovsdb-tool show-log
|
这张图展示了
ovsdb-tool show-log的输出结构，是用于分析 OVS 数据库（OVSDB）中每条变更记录的工具，非常适合用于故障排查、操作审计等场景。🔍 图中各部分说明：
Record number 当前日志条目的编号（如 record 3），表示是第几次变更
Time of Change 变更发生的时间（如 2011-04-13 16:03:52）
Caller’s comment 调用者的信息，显示是哪个命令（如 ovs-vsctl）执行了这个操作
Database changes 实际对 OVSDB 数据表做的更改，例如向 Port、Interface、Bridge 表插入了什么内容✅ 使用场景：
回溯配置修改历史：
谁、什么时候、执行了什么操作？
比如分析 “某个端口怎么被删掉的”。
排查问题引入时机：
比如 Bridge 异常，是不是前几次变更中某个字段被改了。
对比前后状态：
可配合
ovsdb-tool show-log和ovsdb-client dump使用。
三、FORWARDING PATH
3.1 Linux Bridge Design
| Linux Bridge Design
|
这段内容介绍的是 Linux Bridge（Linux 桥接） 的基本设计特点。
🔸 1. Simple forwarding（简单转发）
Linux Bridge（比如
br0）是 Linux 内核提供的一种 L2 网络功能模块，行为类似于一个传统的以太网交换机。
不支持复杂的网络策略；
不理解 OpenFlow；
不提供多层协议控制，功能比较“傻瓜”。
适用于虚拟化场景中简单的二层连接，如 KVM/Libvirt 默认创建的
virbr0。🔸 2. Matches destination MAC address and forwards（匹配目的 MAC 地址并转发）
Linux Bridge 内部维护一个MAC 地址学习表（类似于普通交换机的 FDB 表），处理方式如下：
学习源 MAC 地址 -> 建立 MAC-to-port 的映射；
查找目标 MAC 地址 -> 决定把数据包从哪个端口发出；
如果查无目标 MAC 地址 -> 进行广播（flood）；
不支持复杂的匹配字段（如 IP、端口、协议等）；
🔸 3. Packet never leaves kernel（数据包不会离开内核）
这是 Linux Bridge 性能较好的一个原因：
数据包从一块网卡进入 Linux；
被 Linux Bridge 捕获、处理、转发；
最终从另一块网卡（或 veth、tap 设备）发出；
全程无需上送到用户态，省去了用户态/内核态之间的上下文切换和内存拷贝；
⚠️ 对比 OVS：
Linux Bridge 没有 userspace 控制器；
而 Open vSwitch（OVS）则有
ovs-vswitchd做复杂决策，但代价是第一次数据包需进入用户态。✅ 应用场景总结：
场景 是否适合使用 Linux Bridge 小型虚拟机网络连接 ✅ 是 需要支持 VLAN ✅ 支持（通过 bridge vlan）复杂流量调度 / SDN 控制 ❌ 不适合，建议用 OVS 性能敏感、无需高级策略 ✅ 可用，性能较好 需要 DPDK/流表控制/OpenFlow ❌ 不支持
3.2 Open vSwitch Design
| Open vSwitch Design
|
这段内容介绍了 Open vSwitch（OVS） 的核心设计思想。
🔸 1. 用户态决策（userspace decision-making）
OVS 采用了“控制路径在用户态，转发路径在内核态”的架构：
ovs-vswitchd是用户态守护进程，负责决策、流表管理、控制协议（如 OpenFlow）；
ovs-dp（datapath）模块是内核模块，负责转发和执行动作。这种设计的好处是灵活性强：你可以使用复杂规则、OpenFlow 控制器、策略路由等。
🔸 2. 首包进入用户态（First packet of new flow）
当一个新的流量到达 OVS（如一条 TCP 会话刚建立）时：
它的首个数据包不会立即被内核转发；
而是被送到
ovs-vswitchd，去判断是否允许、应采取何种处理行为（转发、封装、丢弃、镜像等）；该决定形成一条“流表项”（flow entry），被下发到内核 datapath。
🔸 3. 后续命中内核缓存（Cached kernel flow entries）
同一流的后续包，不再进入用户态；
会命中内核中的 fast-path 缓存（类似 TCAM 匹配）；
执行早前下发的动作，处理速度接近线速。
这就形成了“慢速路径（slow path）+ 快速路径（fast path）”的分工模式：
模式 处理位置 作用 Slow Path 用户态 ovs-vswitchd做决策、安装流表 Fast Path 内核模块 快速转发、执行动作 ✅ 优势总结：
特性 OVS 支持 SDN（如 OpenFlow） ✅ 是 高性能转发 ✅ 内核缓存加速 灵活流量控制（QoS、ACL） ✅ 是 复杂多协议隧道（VXLAN/GRE） ✅ 是 DPDK 支持（用户态高速 IO） ✅ 是 与硬件交换芯片对接 ✅ 可 offload
3.3 ovs-vswitchd
| ovs-vswitchd
|
这段内容介绍的是
ovs-vswitchd——Open vSwitch 的核心守护进程。🔹
ovs-vswitchd是系统中的核心组件：
Communicates with outside world using OpenFlow
→ 使用 OpenFlow 协议 与外部控制器通信（如 Ryu、ONOS、OVN 等）Communicates with ovsdb-server using OVSDB protocol
→ 使用 OVSDB 协议 与配置数据库ovsdb-server交互（配置桥、端口等）Communicates with kernel module over netlink
→ 通过 netlink 协议与内核模块（datapath）通信（下发流表、获取统计）Communicates with the system through netdev abstract interface
→ 通过抽象接口 netdev 与 Linux 系统交互（管理设备如 ethX、veth、tap 等）🔹 支持多个独立的数据通道（datapaths/bridges）
一台主机可以有多个逻辑网桥，如
br-int,br-ex,br-tun等，用于不同功能。🔹 包分类器（classifier）支持带通配符的高效流表匹配，并可自动展开复杂规则以加速内核处理
支持 OpenFlow 中的通配规则（如仅匹配 IP 段、端口段等）；
会“爆炸（explode）”这些规则：即将一条宽泛规则展开成多个精确规则下发到内核，提高匹配效率。
🔹 通过 OpenFlow 暴露的同一流表实现镜像（mirroring）、绑定（bonding）和 VLAN 功能
OVS 的所有网络功能都通过「流表规则」来表达，这与传统交换机通过 CLI 配置功能完全不同。
🔹 检查 datapath 的流表计数器以实现：
流表超时（flow expiration）
收集流量统计信息（用于控制器、监控系统）
🔹 常用工具：
工具 作用 ovs-ofctl用于操作 OpenFlow（如添加/查看/删除流表） ovs-appctl用于向 ovs-vswitchd发送运行时命令（如触发内存清理、调试信息等）🧠 总结一句话：
ovs-vswitchd是整个 OVS 的“大脑”：它连接数据库（配置来源）、内核模块（数据面）、控制器（策略控制），将各方统一在一个流表控制模型之下。🗂️ 建议拓展阅读/了解：
ovs-vswitchd如何处理 slow path 到 fast path 的转化
ovs-vswitchd的线程模型和调度性能瓶颈（如处理大量流时 CPU 压力）如何通过
ovs-appctl vlog/set打开调试日志快速排查问题
3.4 OVS Kernel Module
| OVS Kernel Module
|
这段内容讲的是 OVS 的内核模块（Kernel Module），是 Open vSwitch 架构中负责高速转发的“数据面（datapath）”组件。
📘OVS Kernel Module
• Kernel module that handles switching and tunneling
→ 负责**交换（Switching）和隧道封装（Tunneling）**的内核模块。• Fast cache of non-overlapping flows
→ 维护一个不重叠的快速流缓存表，即每条流具有唯一匹配规则（无重叠）以提升匹配效率。• Designed to be fast and simple
→ 设计目标是快速与简洁，专注于高性能包转发。🔍 行为细节：
– Packet comes in, if found, associated actions executed and counters updated. Otherwise, sent to userspace
→ 数据包进来后：
如果能在内核流表中找到匹配项（fast path）：
执行对应动作（如转发、封装、计数）；
否则进入慢路径（slow path）：
发往
ovs-vswitchd用户态做决策。– Does no flow expiration
→ 内核模块不主动删除流表项（过期检测由ovs-vswitchd完成）。– Knows nothing of OpenFlow
→ 内核模块不理解 OpenFlow，它只理解“流 → 动作”的映射，由用户态下发。🔧 功能支持：
• Implements tunnels
→ 直接在内核模块中支持各类隧道协议（VXLAN、GRE、Geneve 等），提高性能，避免上送用户态。🛠️ 调试工具：
• Tools: ovs-dpctl
→ovs-dpctl是用于操作内核 datapath 的工具：
命令 功能 ovs-dpctl show查看当前 datapath 及其端口 ovs-dpctl dump-flows显示当前内核中的流表项 ovs-dpctl del-flow删除指定流表项 ovs-dpctl add-flow手动添加流表项（测试用途） 🧠 总结一句话：
OVS 内核模块是专注高速转发的数据面，不做策略，不懂 OpenFlow，只执行由用户态下发的规则。
3.5 Userspace Processing
| Userspace Processing
|
这段内容讲的是 OVS 用户态处理流程（Userspace Processing），即数据包没有命中内核流表时的处理过程。
• Packet received from kernel
→ 数据包从内核 datapath（fast path）上传到用户态（慢路径）。• Given to the classifier to look for matching flows; accumulates actions
→ 传给 OVS 的分类器（classifier），尝试匹配现有流表，并累积匹配到的动作集（actions）。• If “normal” action included, accumulates actions from “normal” processing, such as L2 forwarding and bonding
→ 如果匹配规则中包含"normal"动作（代表标准交换行为）：
- 则会自动调用 OVS 的内建模块（如 MAC 学习、L2 转发、链路聚合）来生成具体动作。
• Actions accumulated from configured modules, such as mirroring
→ 除了正常转发，动作集还可能包含配置的额外模块（如镜像、限速、QoS 等）的动作。• Prior to 1.11, an exact match flow is generated with the accumulated actions and pushed down to the kernel module (along with the packet)
→ 在 OVS 1.11 之前的版本中：
- 一旦用户态完成处理，会生成一个 精确匹配流表项（exact match flow）；
- 将该项 推送回内核 datapath，并把当前数据包也直接发送出去；
- 后续相同的数据包将直接命中这个流表项，不再进入用户态，提高性能。
🔍 补充说明：什么是“normal”动作？
在 OVS 中，
action=normal表示使用内建的“交换逻辑”，类似 Linux bridge 的行为，包括：
- MAC 学习（Learning）
- 基于 MAC 的 L2 转发
- STP 处理
- 端口 bonding / failover 等
也就是说，这条规则并不显式指定
output:port，而是交给内置算法决定。✅ 总结一句话：
OVS 用户态负责复杂包处理逻辑，如 MAC 学习、镜像、策略等，并会把结果“缓存”为内核精确流规则，下次直接命中，加速转发。
3.6 Kernel Processing
| Kernel Processing
|
这段描述的是 Open vSwitch (OVS) 中 内核态 datapath 的核心处理逻辑。
✅ Packet arrives and header fields extracted
数据包到达，提取头部字段
当网络接口（如虚拟网卡、物理网卡、veth、tap 等）收到一个数据包后，OVS 的内核模块首先会提取这个包的关键字段。
通常提取的包括：
源/目的 MAC 地址
VLAN tag
IP 头部（源/目的 IP 地址）
协议类型（TCP/UDP/ICMP）
TCP/UDP 端口号
输入端口等
🧠 作用：这些字段构成了 packet 的 “特征键”，用来查找是否已有匹配规则。
✅ Header fields are hashed and used as an index into a set of large hash tables
将这些头部字段哈希，用于查找大型哈希表中的流表项
把上述字段组合成一个 “key”，使用哈希函数生成一个索引值。
这个值用来查找内核中的 flow cache（也称为 fast path flow table），它是一个大型哈希表。
每个 entry 表示一个精确匹配流（exact match flow）。
🧠 作用：提高流匹配效率，避免顺序查找；这是实现高性能转发的关键。
✅ If entry found, actions applied to packet and counters are updated
如果找到匹配项，则对数据包执行对应动作，并更新计数器
典型的动作包括：output、drop、modify、mirror、push/pop VLAN 等；
同时更新这个 flow entry 的统计数据：如匹配次数、转发的字节数等。
🧠 性能关键点：整个过程发生在内核空间，不需要用户态参与，非常快。
✅ If entry is not found, packet sent to userspace and miss counter incremented
如果没有匹配项，则将数据包送到用户态（ovs-vswitchd），并增加 miss 计数器
用户态收到这个 packet-in 后，会由
ovs-vswitchd：
查找 OVSDB 中的 bridge 配置；
查 OpenFlow 中的策略；
执行动作（如 flood、mirror、学习等）；
生成一个新的 flow（精确匹配），下发到内核态 datapath；
同时这个数据包也被重新注入执行动作。
🧠 结果：后续同类数据包就不会再 miss，而是命中这个刚装下来的 flow。
🛠️ 补充工具建议：
查看内核 datapath 中当前所有 flow：
sudo ovs-dpctl dump-flows
- 查看 miss 情况：
sudo ovs-dpctl show
- 查看新 flow 安装记录：
sudo tail -f /var/log/openvswitch/ovs-vswitchd.log
3.7 Megaflows
| Megaflows
|
Megaflows 是 OVS 1.11 版本引入的一个重要优化，理解它是理解新旧 OVS datapath 行为区别的关键点。以下是详细解释：
✅ 什么是 Megaflow？
Megaflow 是指一种 “合并多个类似流（microflow）” 的方式，将它们统一成一个更粗粒度、更具通配性质的 datapath 规则。
在 1.11 之前，OVS 的 datapath 只会对每一个精确五元组（或七元组）生成一条 microflow（精确匹配项），也就是：
eth_type=ip, ip_proto=6, src=192.168.1.1, dst=192.168.1.2, src_port=1234, dst_port=80
每个流都要单独匹配，内核中存储的 flow 表也就会很大，CPU cache 压力大，性能不如 Linux bridge。🚀 Megaflow（1.11 之后）做了哪些不同的事情？
引入 wildcard 匹配的内核 datapath flow：
用户空间 OVS（
ovs-vswitchd）不再直接为每一个精确流生成一个内核 flow。而是根据实际行为模式（匹配字段、动作、配置等）分析哪些字段可以被 wildcard（通配）。
最终只在 datapath 安装一条 宽泛的 flow，可以匹配多个 microflow。
举例说明：
假设你用如下 OpenFlow 规则允许 TCP 80：
in_port=1,ip,nw_proto=6,tp_dst=80 actions=output:2
在 没有 megaflow 的情况下：
每一个 src_ip/src_port 的变化，都会导致内核 datapath 添加一条新的 entry。
在 有 megaflow 的情况下：
ovs-vswitchd分析发现 src_ip/src_port 不影响动作（output:2），于是生成一个：in_port=1,ip,nw_proto=6,tp_dst=80 actions=2 → 这条 flow 可以匹配很多不同的 TCP 会话（只要是端口 80）。🧠 Megaflow 是如何决定 wildcard 的？
取决于以下几个因素：
OpenFlow 匹配字段：你 Flow 表里匹配了哪些字段。
Flow 的动作（actions）：是否依赖某些字段（如 resubmit 或 output 到特定端口）。
Switch 全局配置：如 bond、STP、VLAN 等配置是否影响 forwarding。
📈 性能收益？
由于内核只需维护少量、宽泛的 megaflow：
内核 flow 表更小（降低 cache miss）
减少从用户态 miss 回到
ovs-vswitchd的频率性能逼近 Linux bridge
🔍 查看 megaflow 的方式：
你可以通过如下命令看到当前安装的 megaflow：
ovs-dpctl dump-flows
里面会看到很多 flow 项没有完全匹配字段，而是有 wildcard 字段，比如：recirc_id=0,eth,ip,nw_proto=6,tp_dst=80,actions:2
3.8 Tunnels
| Tunnels
|
Tunnels（隧道） 在 OVS（Open vSwitch）中是一个重要的功能，广泛应用于 跨主机通信 和 overlay 网络（如 OpenStack、Kubernetes 中的 Calico/OVN 等）。下面是详细解释：
✅ 什么是 Tunnel？
在 OVS 中，Tunnel 是一种 虚拟端口（virtual port），它封装原始报文以实现：
跨物理网络的数据转发
多租户隔离（overlay 网络）
灵活的流表控制
每一个隧道口（如 VXLAN/GRE）在 OVS 中都有一个 OpenFlow 端口号，可像普通接口一样进行匹配、动作和控制。
🛠 Tunnel 类型
OVS 支持多种隧道类型：
隧道类型 说明 GRE Generic Routing Encapsulation，简单灵活 VXLAN 常用于 overlay 网络，支持 VNI LISP 支持更复杂的地址映射，较少使用 Geneve 类似 VXLAN，支持更复杂元数据（较新） 你可以通过
ovs-vsctl add-port创建这些隧道口：ovs-vsctl add-port br0 vxlan0 -- set interface vxlan0 type=vxlan options:remote_ip=192.168.1.100 options:key=100
🔍 如何查看隧道接口？使用以下命令：
ovs-dpctl show
你会看到输出类似：system@ovs-system: lookups: hit:1234 missed:56 lost:0 flows: 5 port 1: vxlan_sys_4789 (vxlan) RX packets: 4567 errors: 0 dropped: 0 TX packets: 5678 errors: 0 dropped: 0或通过
ovs-vsctl show：Bridge br0 Port "vxlan0" Interface "vxlan0" type: vxlan options: {remote_ip="192.168.1.100", key="100"}🔑 Tunnel key 设置方式
隧道中的关键字段（称为 tunnel key）用于标识不同 overlay：
VXLAN 中的 key 就是 VNI（VXLAN Network Identifier）
GRE 的 key 是一个整数 ID
设置方式：
静态设置：通过
ovs-vsctl时固定写死key或remote_ip动态设置：通过 OpenFlow 的
set_tunnel:动作实现：actions=set_tunnel:100,output:vxlan0🔄 OpenFlow 中如何控制隧道流量？
你可以像控制物理口一样使用：
ovs-ofctl add-flow br0 "in_port=1,actions=set_tunnel:100,output:vxlan0" ovs-ofctl add-flow br0 "tun_id=100,actions=output:2"🧠 总结
概念 含义 隧道口 虚拟接口，行为类似物理口 类型 GRE、VXLAN、LISP 等 key VXLAN-VNI / GRE-Key，用于区分 overlay 控制方式 静态设置 or OpenFlow 动态设置 查看工具 ovs-dpctl show、ovs-vsctl show
四、UTILITIES
4.1 OVS and Openflow
| OVS and Openflow
|
这段内容简要介绍了 Open vSwitch (OVS) 与 OpenFlow 的关系，以及如何通过工具
ovs-ofctl和ovs-appctl与 OpenFlow 流表进行交互和调试。✅
ovs-ofctl与 OpenFlow 模块通信ovs-ofctl show <bridge>
ovs-ofctl dump-flows <bridge>
ovs-ofctl add-flow <bridge> <flow>
ovs-ofctl del-flows <bridge> [flow]
ovs-ofctl snoop <bridge>
show：显示指定 bridge 的基本信息（控制器连接状态、端口等）
dump-flows：列出当前所有 OpenFlow 流表项
add-flow：向指定 bridge 添加流表项
del-flows：删除流表项（可精确指定）
snoop：监听 OpenFlow 消息（调试时观察 controller 与 switch 间通信）📘 解读：
ovs-ofctl是一个 CLI 工具，用于直接与 OVS 的 OpenFlow 通道 交互；可以模拟 controller 的行为，人工下发、修改、查看 OpenFlow 规则。
✅ OpenFlow 扩展能力
🔸 Resubmit Action
模拟多表机制：在一个表里多次重定向 flow 到不同的 match/action 流程；
类似 pipeline 的处理逻辑。
🔸 NXM（Nicira Extended Match）
Nicira 扩展匹配字段；
支持更丰富的 header 匹配条件，比如 tunnel ID、metadata、regX、ct_state 等。
🔸 Registers（寄存器）
提供 8 个 32-bit 的通用寄存器 reg0～reg7；
用于在流表之间传递中间状态，比如用于策略路由、NAT、回环检测等高级功能。
🔸 多控制器支持（fine-grained control）
支持精细控制多个 OpenFlow 控制器的连接方式、优先级、角色等；
比如主用/备用控制器、独立控制器等场景。
✅ 查看隐藏流表项（非用户显式配置的系统内部流）
ovs-appctl bridge/dump-flows <bridge>
ovs-ofctl dump-flows只能看到用户下发的 OpenFlow 规则；而
ovs-appctl bridge/dump-flows能看到所有流表项，包括：
fail-open 模式下的 fallback 流
in-band 模式下用于维持控制连接的内部流
OVS 自动生成的“防环”规则、学习型规则等
🛠️ 示例：手动下发并查看 OpenFlow 流表
# 添加一个简单的流表项：从端口1进来的包全部发到端口2
ovs-ofctl add-flow br0 "in_port=1,actions=output:2"# 查看流表项
ovs-ofctl dump-flows br0# 删除所有流表项
ovs-ofctl del-flows br0
4.2 ovs-ofctl show <br>
| ovs-ofctl show <br>
|
Open vSwitch (OVS) 的
ovs-ofctl show命令的输出，具体内容是关于网络交换机端口和接口的配置信息。该输出显示了 Open vSwitch 上连接的网络端口（port)信息，包括物理接口(interface）
eth0和eth1的状态，以及虚拟交换机接口br0的配置。这些信息有助于诊断和配置 Open vSwitch 上的端口和网络链路状态，确保网络连接的稳定性和性能。
4.3 ovs-ofctl dump-flows <br>
| ovs-ofctl dump-flows <br>
|
这段内容展示了使用
ovs-ofctl dump-flows br0查看 OVS 中默认流表的输出结果，并解释了默认流项的含义。下面是详细翻译与解读：ovs-ofctl dump-flows br0
表示：查看名为br0的 Open vSwitch 网桥中的所有 OpenFlow 流表项。🧾 输出解释：
逐项说明如下：
🧠 解读：
字段 含义 cookie=0x0用户自定义标识，用于标记流项，控制器可通过它识别流来源 duration=4.05s流表项存在的时间（秒），此处表示该流项生效已 4.05 秒 table=0表示这是 OpenFlow 流表的第 0 张表（默认表） n_packets=8匹配该流表项的数据包数量，共 8 个 n_bytes=784匹配的数据总字节数为 784 字节 idle_age=0距离上次匹配该流的时间（秒），为 0 表示刚刚匹配过 priority=0流项的优先级，值越大优先级越高，此处为最低优先级 actions=NORMAL动作为 “正常转发”，即使用 OVS 的 L2 学习转发逻辑（类似传统 Linux Bridge） ✅ 示例：添加一条高优先级规则覆盖默认行为
这是 OVS 启动后默认存在的基础流项，匹配所有未命中更高优先级规则的流量；
priority=0+ 无匹配字段 ⇒ 默认规则（“兜底”规则）；
actions=NORMAL⇒ 使用 L2 数据包学习与转发，即目的 MAC 学习逻辑；
简单理解为传统交换机的行为：学习源 MAC，按目标 MAC 转发；
如果你没有手动下发 OpenFlow 规则，那么只会看到这个“默认规则”。
# 将 in_port=1 的数据包转发到端口 2
ovs-ofctl add-flow br0 "priority=100,in_port=1,actions=output:2"# 查看所有流表项
ovs-ofctl dump-flows br0
执行后你会看到新的流表项，以及默认流表项依然保留，但会被新规则“覆盖”优先匹配。
4.4 Hidden Flows
| Hidden Flows
|
✅ Hidden Flows（隐藏流表）
Open vSwitch 中存在内部使用的隐藏流表项，这些流具有 超高优先级（>65535），不受控制器配置控制。
🔍 特点
优先级高于 OpenFlow 最大值（65535）
控制器看不见，
ovs-ofctl dump-flows也无法列出保障 OVS 的管理通信与容灾机制
只能通过
ovs-appctl bridge/dump-flows <bridge>查看🧱 类型及作用
类型 优先级 作用 In-band control ≥180000 保证 OVS 到控制器等管理路径的通信 Fail-open 0xf0f0f0 (15790320) 控制器失联时自动允许所有流量通过（容灾） 📌 示例命令
ovs-appctl bridge/dump-flows br0
4.5 Kernel Datapath
| Kernel Datapath
|
这是对 OVS Kernel Datapath 调试方式的简要说明，重点介绍了
ovs-dpctl工具的基本用法。Open vSwitch（OVS）将实际的报文转发工作交由内核模块完成，这部分被称为 datapath。
工具ovs-dpctl用于与内核中的 datapath 通信，常用于调试和查看内核态的转发状态。🔧 工具：
ovs-dpctl这是一个命令行工具，用于直接操作 OVS 的 内核模块（datapath），不依赖于 OVSDB，也不需要
ovs-vswitchd进程。✅ 查看 datapath 与接口：
ovs-dpctl show
📘 作用：
列出所有 datapath（通常一个）
展示每个 datapath 绑定的端口（网卡、patch口、veth等）
显示 datapath 的统计信息（packets, dropped, errors）
🧾 示例输出：
system@ovs-system: lookups: hit:120 miss:3 lost:0 flows: 1 port 0: ovs-system (internal) port 1: ens3 port 2: patch-int✅ 查看内核中缓存的流表项：
ovs-dpctl dump-flows
📘 作用：
列出 内核态缓存的精确流表项（datapath flow cache）
包含匹配字段、action、计数器等信息
这些是由
ovs-vswitchd在处理首次包时生成并下发的“精确匹配规则”🧾 示例输出：
recirc_id(0),in_port(1),eth_type(0x0800),ipv4_src=10.0.0.1,... actions:2 root@server1:~# ovs-dpctl dump-flows recirc_id(0),in_port(3),eth(src=52:54:00:4a:c3:3b,dst=52:54:00:d0:13:4d),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:98, used:2.148s, actions:4 recirc_id(0),in_port(4),eth(src=52:54:00:d0:13:4d,dst=52:54:00:4a:c3:3b),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:98, used:2.149s, actions:3 root@server1:~#🔄 用户态与内核态配合流程：
第一个包到达，找不到内核流表项，送到
ovs-vswitchd用户态处理；用户态通过 OpenFlow classifier 匹配 wildcard 规则并生成 action；
将生成的 精确流表项 插入内核 datapath，后续相似包直接命中，提升性能；
这些流表项就是通过
ovs-dpctl dump-flows能看到的内容。🔍 总结对比：
工具 对象 功能 ovs-dpctl内核态 datapath 查看流表缓存、端口绑定、收发统计等 ovs-ofctlOpenFlow 流表 操作用户态的流匹配逻辑 ovs-vsctlOVSDB 配置数据库 配置桥、端口、控制器等拓扑结构
4.6 ovs-dpctl show
| ovs-dpctl show
|
ovs-dpctl show命令的输出，这是 Open vSwitch 的一个命令，用于显示有关数据路径的详细统计信息。以下是图片中各部分内容的详细解读：1. lookups: hit, missed, lost
hit: 188056: 表示数据包成功命中现有的表项（即这些数据包在流表中找到了匹配项并被成功处理）。
missed: 7722: 表示有 7722 个数据包没有找到匹配的流表项，并被发送到用户空间进行处理。
lost: 0: 表示没有数据包丢失，即所有数据包都被成功处理或者发送到用户空间。
2. flows (流表条目)
flows: 2: 表示 Open vSwitch 中当前有 2 条流表条目。
3. masks
masks: hit: 199268 total: 1 hit/pkt: 1.02: 这个统计信息表示掩码的命中情况，
hit: 199268表示掩码的命中次数，总计每个数据包的命中次数为 1.02。4. 端口信息
接下来的部分列出了 Open vSwitch 中的各个端口信息：
port 0: ovs-system (internal): 端口 0 是内部接口，名为
ovs-system，通常用于 Open vSwitch 的内部通信。port 1: br0 (internal): 端口 1 是内部端口，连接到
br0（虚拟交换机的接口）。port 2: eth0: 端口 2 是物理接口
eth0，它是物理网络接口之一。port 3: eth1: 端口 3 是物理接口
eth1，它是另一个物理网络接口。总结：
"hit" 表示数据包成功命中了流表中的现有条目，处理速度较快。
"missed" 表示数据包没有匹配到现有的流表条目，因此被送往用户空间进一步处理。
"lost" 代表丢失的数据包数量，这里为 0，表示没有数据包丢失。
每个端口的名称和类型被列出，包括虚拟交换机接口（如
ovs-system和br0）以及物理接口（如eth0和eth1）。此信息对于网络管理员来说非常重要，可以帮助诊断数据包在 Open vSwitch 中的流转情况，特别是在流表匹配、数据包处理等方面的性能问题。
4.7 ovs-dpctl dump-flows
| ovs-dpctl dump-flows
|
ovs-dpctl dump-flows是 Open vSwitch (OVS) 中的一个命令，用于查看当前的数据路径 (datapath) 上的所有流表条目。此命令会显示所有当前匹配的数据流，包含匹配条件、数据包计数、字节计数、使用的时间以及执行的动作等信息。这里显示了 Open vSwitch 中的流表条目，并展示了流表匹配的变化。具体来说，这些流表条目是在 OVS 1.11 之前和之后的不同表现。以下是详细解析：
1. OVS 1.11 之前的流表条目 (Exact Match)
在 OVS 1.11 之前，流表条目是精确匹配的，这意味着流表中的每一条规则必须完全匹配包头中的所有字段。两个示例流表条目如下：
第一个条目：
in_port(2), eth(src=50:54:00:00:00:01, dst=50:54:00:00:00:03), eth_type(0x0800), ipv4(src=192.168.0.1, dst=192.168.0.2, proto=1, tos=0, ttl=64, frag=no), icmp(type=8, code=0), packets:3, bytes:294, used:0.185s, actions:3
该条目匹配进入端口 2 的数据包，要求源 MAC 地址为50:54:00:00:00:01，目标 MAC 地址为50:54:00:00:00:03，协议为 IPv4，源 IP 地址为192.168.0.1，目标 IP 地址为192.168.0.2，协议号为 ICMP 类型 8，代码 0。第二个条目：
in_port(3), eth(src=50:54:00:00:00:03, dst=50:54:00:00:00:01), eth_type(0x0800), ipv4(src=192.168.0.2, dst=192.168.0.1, proto=1, tos=0, ttl=64, frag=no), icmp(type=0, code=0), packets:3, bytes:294, used:0.205s, actions:2
这个条目匹配进入端口 3 的数据包，要求源和目标 MAC 地址分别为50:54:00:00:00:03和50:54:00:00:00:01，以及 IPv4 协议、ICMP 类型为 0。2. OVS 1.11 之后的流表条目 (Wildcard Match)
从 OVS 1.11 开始，流表条目可以包含“通配符” (wildcards)，即可以在某些字段上不严格匹配，而是允许这些字段的值可以是任意值。这有助于简化流表规则并提高性能。
第一个条目：
in_port(3), eth(src=50:54:00:00:00:03, dst=50:54:00:00:00:01), eth_type(0x0800), ipv4(src=192.168.0.2/0.0.0.0, dst=192.168.0.1/0.0.0.0), proto=1/0, tos=0/0, ttl=64/0, frag=no/0x2, icmp(type=0/0, code=0/0), packets:95, bytes:9310, used:0.425s, actions:2
该条目使用了通配符。例如，源 IP 地址192.168.0.2可以匹配任意 IP 地址（192.168.0.2/0.0.0.0）。其他字段也可以有类似的通配符设置，这表示某些字段的具体值不再被严格要求。第二个条目：
in_port(2), eth(src=50:54:00:00:00:01, dst=50:54:00:00:00:03), eth_type(0x0800), ipv4(src=192.168.0.1/0.0.0.0, dst=192.168.0.2/0.0.0.0), proto=1/0, tos=0/0, ttl=64/0, frag=no/0x2, icmp(type=8/0, code=0/0), packets:95, bytes:9310, used:0.525s, actions:3
这个条目同样使用了通配符，源和目标 IP 地址、协议字段等都允许匹配多个值。总结
OVS 1.11 之前，流表条目需要精确匹配数据包的各个字段。
OVS 1.11 之后，流表支持通配符匹配，即某些字段可以使用通配符来匹配任意值，从而使得流表规则更加灵活并提高性能。
4.8 ovs-appctl
| ovs-appctl
|
ovs-appctl是 Open vSwitch (OVS) 提供的一个非常实用的控制命令行工具，用于在运行时与 OVS 的各个守护进程（daemon）进行交互。它可以用于调试、状态查询、日志级别控制等操作。下面是对你提供内容的进一步解释和补充：🛠
ovs-appctl简介
ovs-appctl是一个用于控制 OVS 守护进程（如ovs-vswitchd、ovsdb-server等）的工具，功能类似于 "runtime CLI"。🔹 常用格式：
ovs-appctl [-t <target-daemon>] <command>
-t <target>：指定目标守护进程（默认是ovs-vswitchd）
<command>：具体要执行的命令📋 通用命令（所有 daemon 支持）
命令 说明 help列出目标守护进程支持的所有命令 version显示版本和编译信息 vlog/list显示支持的日志模块及当前日志级别 vlog/set [spec]设置日志级别，例如： vlog/set dpif:dbgvlog/reopen重新打开日志文件，适用于 logrotate vlog/close关闭日志文件输出，改为标准输出 🔍 示例操作
1. 查看支持的所有命令（默认目标是
ovs-vswitchd）：ovs-appctl list-commands
2. 指定ovsdb-server查看命令：ovs-appctl -t ovsdb-server list-commands
3. 设置日志级别为调试：
ovs-appctl vlog/set dpif:dbg
4. 查看当前日志模块状态：ovs-appctl vlog/list
📘 进阶使用：特定目标支持的特色命令
每个 daemon（如
ovs-vswitchd、ovsdb-server、ovs-controller）都支持一套专属控制命令，可通过help查看。比如：
🔹
ovs-vswitchd示例命令：
命令 功能 bond/show显示 bond 接口状态 bridge/dump-flows打印流表 coverage/show显示覆盖率计数器 exit请求 ovs-vswitchd 退出（调试用）
4.9 Flow Debugging
| Flow Debugging
|
这是一个用于演示 Open vSwitch (OVS) 流表调试的简单例子，使用
ovs-ofctl添加的 OpenFlow 流规则模拟了一个基础防火墙逻辑。我们将逐条解析这组流规则，并指出它的问题和改进建议。📋 示例规则分析（按优先级执行）：
✅ 规则 1：
priority=100,tcp,in_port=1 actions=resubmit:4000
含义：
所有从端口 1 进入的 TCP 流量，不直接处理，而是“重提交”给表 4000（模拟 pipeline 的下一阶段）继续匹配。
resubmit是 OVS 的扩展动作，用于模拟 OpenFlow 的多表处理。✅ 规则 2：
priority=100,tcp,in_port=4000,tp_dst=80 actions=NORMAL
含义：
所有进入虚拟端口 4000（也就是刚才 resubmit 来的）的 TCP 且目标端口是 80 的流量，允许正常转发。
其他 TCP 流量未匹配，默认 drop（因为没有更低优先级的匹配动作）。
✅ 规则 3：
priority=90,in_port=1 actions=NORMAL
含义：
从端口 1 进来的 非 TCP 流量（因为 TCP 流量已经匹配在更高优先级），允许正常转发。
✅ 规则 4：
priority=100,in_port=2 actions=NORMAL
含义：
所有从端口 2 进来的流量（无论什么协议），全部允许。
4.10 Tracing Flow (ICMP Allowed)
Tracing Flow (ICMP Allowed)  |
4.11 Tracing Flow(TCP allowed)
| Tracing Flow (TCP allowed) |
4.12 Tracing Flow (TCP denied)
Tracing Flow (TCP denied) |
扫一扫
938
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
