用OVS流表玩转三层路由：ARP代答与转发规则全解析

在虚拟网络里搞三层通信，我最早的习惯是拉一台Linux虚拟机配好IP转发，或者老老实实开一个网络命名空间当路由器。直到有次在云平台排障，发现数据流根本没走到预期路径，手上的Open vSwitch流表工具却显示里面居然能匹配IP地址，这才意识到：原来OVS这个"二层交换机"完全可以用纯流表的方式模拟出一个三层网关。

后来我把这个思路完整跑了一遍，用OVS的流表替代内核协议栈，实现了两个网段的互通。整个过程非常有意思——它把路由器里那些"黑盒"行为拆成了ARP代答、MAC重写、TTL递减一条条看得见摸得着的规则。这篇文章就把我的完整实验过程记录下来，包括流表怎么设计、为什么这么设计、实测怎么验证、哪些细节不写清楚一定会翻车。不管你是想搞SDN控制器下发路由，还是单纯想弄懂OpenStack里ovs agent l3那堆流表到底在干什么，这篇都值得对照着操作一遍。

1. 为什么偏偏要用流表来干路由的活

1.1 从"二层交换"到"路由转发"，OVS的能力边界

先说一个很多人忽略的背景。OVS是Open vSwitch的缩写，在传统认知里它就是虚拟交换机，负责MAC地址学习和帧转发。但OVS同时实现了OpenFlow协议，这意味着你可以绕过它的L2自学习机制，直接用流表去匹配数据包里的任意字段，包括IP头里的源地址、目的地址、协议号，甚至TTL。

这一下就把它的能力边界推到了三层。一个数据包进到OVS，我可以先看它是ARP还是IP，如果是IP再看目的IP走哪条"路由"，确定出接口后修改源MAC、目的MAC，把TTL减一，再从对应端口扔出去。这一套动作组合起来，和一台路由器做的事没有本质区别。

不过这里有个容易混淆的点：OVS官方术语里的L3往往指物理设备上"带路由功能的交换机"，而OpenFlow流表里实现的L3是纯数据面的策略转发。两者最终效果类似，但实现路径完全不同。流表L3更像是在一个可编程的转发芯片上写微码——灵活到极致，但也意味着所有路由逻辑都要自己用规则一点一点铺出来。

1.2 三条技术路线对比：纯流表、命名空间路由器、SDN控制器

如果要在虚拟环境里实现路由器功能，市面上主流有三条路，我做个横向对比：

我在实验里选择的是第三条路，也是最底层、最考验对OpenFlow理解的方式。把它跑通之后，你再看Neutron DVR那套机制，会发现很多流表动作似曾相识，因为生产系统的设计思路就是从这里长出来的。

2. 拆开路由器：L3流表背后要做的那几件脏活

2.1 跨网段报文的完整生命周期

想用流表实现L3，第一步是把"路由器转发一个IP包"这件事拆成可操作的原子步骤。假设有台主机A在192.168.1.0/24网段，它要给192.168.2.0/24网段的主机B发包，整个过程是这样的：

1. A发现目的IP不在自己网段，于是把包发给默认网关192.168.1.1。
2. A先广播ARP请求，问"192.168.1.1的MAC地址是多少"，拿到网关MAC后才构造以太网帧。
3. 以太网帧的源MAC是A自己的MAC，目的MAC是网关的MAC，但IP头的源IP是A，目的IP是B。
4. 路由器（也就是OVS）从入接口收到这个帧，发现目的MAC是自己，于是剥掉二层交给三层处理。
5. 三层查路由表，发现192.168.2.0/24不在本地直连网段，命中路由表项，确定出接口是连B网段的那个口。
6. 路由器把TTL减一，把源MAC改成出接口的MAC，把目的MAC改成B的MAC（或下一跳的MAC），重新封装成帧，从出接口送出去。

OVS流表要复刻的就是第4到第6步。难点在于，内核协议栈做这些事是"理所当然"的，而在OVS里每个动作都要显式写出来，漏一个包就断了。

2.2 用OpenFlow字段还原路由动作

对照上面的流程，我把路由器的每个动作映射到具体的OpenFlow写法：

这里面最容易被忽略的是ARP代答。很多人写L3流表时会下意识觉得"ARP不归我管"，但你想让主机A拿到网关MAC，OVS必须自己当那个应答者。好在OpenFlow对ARP字段的读写能力很强，NXM_OF_ARP_OP、NXM_OF_ARP_SPA、NXM_OF_ARP_SHA这些扩展字段足够我们手工拼一个合法的ARP应答包。

2.3 为什么多级table比一张大表更靠谱

设计流表时，我强烈建议用多级table组成流水线，而不是把所有规则塞进一张表用priority硬撑。原因有两点：

第一是逻辑清晰。路由器的转发流程本来就是分阶段的：入口分流、ARP处理、路由查询、二层转发。用table 0、table 10、table 20分别对应这些阶段，每条规则只干一件事，出问题一眼就能定位。

第二是避免规则碰撞。如果所有规则都在一张表里，必然会出现一条IP规则和一条ARP规则同时匹配同一个包的情况，优先级一旦设计错就全乱。分表后，用resubmit把包从一个表导向另一个表，天然隔离了不同类别的匹配逻辑，优先级只在表内比较就够了。

以我的实验为例，管线是：

code复制table 0（入口分流） → ARP包 → table 10（ARP代答）
                   → IP包  → table 20（路由查询与转发）

2.4 双向流量：只配一条路由的后果

流表L3最容易犯的错误是只管了一个方向。A到B通了，B到A全丢。原因也很简单：OVS是无状态的，你给table 20配了"目的192.168.2.10走veth2出去"，但B回A的包是目的192.168.1.10，没有对应规则，自然被默认drop吃掉。

所以配置路由流表时，必须显式地写出所有方向的转发规则。这个"方向"不仅指正反两个网段，还包括跨多跳时每一跳的匹配规则。刚开始做实验的人在排障时经常陷入困惑：明明ping的时候第一个包好像有响应，后面全超时，级可能就是回程丢了。

3. 搭一个最小复现环境：两个Namespace，一个OVS网桥

3.1 拓扑与地址规划

我不会用两台真实虚拟机，而是用Linux的网络命名空间模拟两台独立主机，再用一个OVS网桥当"路由器"。拓扑非常精简：

code复制ns1 (192.168.1.10/24) ── veth1_p ── veth1 ── [br0 OVS] ── veth2 ── veth2_p ── ns2 (192.168.2.10/24)
       网关 192.168.1.1                                       网关 192.168.2.1

分配到的关键参数如下：

MAC地址我直接固定，省去动态学习的麻烦：

这里提一句，网关的MAC和它负责网段内主机的MAC在同侧时可以相同，实际环境中不存在这种情况，因为我们只是借用流表模拟路由器的接口地址，让OVS既当网关又当下一条，减少一个需要学习的MAC。

3.2 命令逐步创建

整个环境搭建大概是这些命令，我按顺序贴出来：

bash复制# 1. 创建两个网络命名空间
ip netns add ns1
ip netns add ns2

# 2. 创建两对veth
ip link add veth1 type veth peer name veth1_p
ip link add veth2 type veth peer name veth2_p

# 3. 把其中一端放入命名空间
ip link set veth1_p netns ns1
ip link set veth2_p netns ns2

# 4. 创建OVS网桥并把另一端挂上去
ovs-vsctl add-br br0
ovs-vsctl add-port br0 veth1
ovs-vsctl add-port br0 veth2

# 5. 配置主机侧命名空间
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip link set veth1_p address 02:00:00:00:01:01
ip netns exec ns1 ip addr add 192.168.1.10/24 dev veth1_p
ip netns exec ns1 ip link set veth1_p up
ip netns exec ns1 ip route add default via 192.168.1.1

ip netns exec ns2 ip link set lo up
ip netns exec ns2 ip link set veth2_p address 02:00:00:00:02:02
ip netns exec ns2 ip addr add 192.168.2.10/24 dev veth2_p
ip netns exec ns2 ip link set veth2_p up
ip netns exec ns2 ip route add default via 192.168.2.1

# 6. 确保OVS侧veth端口up
ip link set veth1 up
ip link set veth2 up

这里有个细节容易踩坑：如果OVS侧端口没有up，数据包根本进不了流表。ip link set veth1 up这步不能省，也别指望ovs-vsctl add-port会自动帮你把端口拉到up状态。

3.3 验证基础连通性：先在二层层面踩一遍

流表没配之前，OVS网桥默认行为是把所有广播帧和未知单播帧泛洪，所以ns1发ARP广播时理论上能泛洪到veth2，但不可能收到正确应答，因为没有人认识192.168.1.1和192.168.2.1。我建议在做流表前先测一下：

bash复制ip netns exec ns1 ping -c 2 192.168.2.10

预期结果就是超时。这一步不是白做的，它可以确认命名空间、veth、链路本身没配错。如果这里出现了"Network is unreachable"，多半是默认网关没有配上，先回第5步检查。

另一个可选验证：在OVS里临时加一条泛洪规则再测二层连通。不过我们马上要清掉所有默认行为，直接进入到流表配置环节就行。我习惯在做流表前先dump一次现有流表，确认当前只有NORMAL规则或者什么都没有，心里有个底。

4. 配置L3流表的完整操作：一条一条下，讲清楚为什么这么写

4.1 Table 0：入口分流

首先要清空网桥上可能存在的默认流表，然后建立管道入口。这里有一个重要决定：所有进入br0的数据包，默认都是丢弃，只有明确的ARP和IP包才放行进后续table。

bash复制ovs-ofctl -O OpenFlow13 del-flows br0

# 入口分流：ARP进table 10，IP进table 20
ovs-ofctl -O OpenFlow13 add-flow br0 "table=0,priority=100,arp actions=resubmit(,10)"
ovs-ofctl -O OpenFlow13 add-flow br0 "table=0,priority=100,ip actions=resubmit(,20)"
# 兜底丢弃
ovs-ofctl -O OpenFlow13 add-flow br0 "table=0,priority=0,actions=drop"

为什么优先匹配ARP和IP的优先级都设为100，而不是非此即彼？OpenFlow里数据包类型不只这两种，还有IPv6、MPLS等。如果只写了ARP和IP两条高优先级规则，其他类型会掉到priority=0的drop规则被丢弃，这正好满足我们的预期：这个"路由器"只处理我们关心的IPv4流量。

resubmit(,10)里的第一个参数留空表示继续使用当前包的入端口，第二个参数是目标table号。这个动作不会改变包的字段，只是把流程跳转到指定table继续匹配，相当于"goto"。

4.2 Table 10：ARP代答的字段搬运动作

Table 10要完成的是"AGENT L3"里最重要的一个功能——网关ARP代答。当主机想知道网关MAC时，OVS得能应答。下面这条规则专门处理ns1对192.168.1.1的ARP请求：

bash复制ovs-ofctl -O OpenFlow13 add-flow br0 "table=10,priority=200,arp,arp_op=1,arp_tpa=192.168.1.1 actions=load:2->NXM_OF_ARP_OP[],move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],move:NXM_OF_ARP_SHA[]->NXM_OF_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:02:00:00:00:01:01->eth_src,set_field:02:00:00:00:01:01->arp_sha,set_field:192.168.1.1->arp_spa,IN_PORT"

看起来长，拆开看其实很直白：

1. load:2->NXM_OF_ARP_OP[]：ARP操作码从1（请求）改成2（应答）。
2. move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[]：把请求方MAC挪到以太网目的地址，让应答单播回去。
3. move:NXM_OF_ARP_SHA[]->NXM_OF_ARP_THA[]、move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[]：把请求方的硬件地址和协议地址搬到应答包的目标字段。
4. set_field:...->eth_src、set_field:...->arp_sha、set_field:192.168.1.1->arp_spa：把应答包的源MAC、发送方硬件地址、发送方协议地址都填成网关自己的信息。
5. IN_PORT：从入端口原路返回。

这里有个动作顺序的坑必须提醒：如果你先set_field:02:00:00:00:01:01->eth_src，再去move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[]，那么目的地址也会变成网关MAC，请求方根本收不到应答。正确的顺序一定是"先搬旧字段，再写新字段"。

同理，192.168.2.1这边的ARP代答规则照葫芦画瓢，只是IP和MAC换成p2侧网关的参数：

bash复制ovs-ofctl -O OpenFlow13 add-flow br0 "table=10,priority=200,arp,arp_op=1,arp_tpa=192.168.2.1 actions=load:2->NXM_OF_ARP_OP[],move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],move:NXM_OF_ARP_SHA[]->NXM_OF_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:02:00:00:00:02:02->eth_src,set_field:02:00:00:00:02:02->arp_sha,set_field:192.168.2.1->arp_spa,IN_PORT"

最后给table 10加一条兜底丢弃规则，避免未被识别的ARP请求被泛洪出去：

bash复制ovs-ofctl -O OpenFlow13 add-flow br0 "table=10,priority=0,actions=drop"

4.3 Table 20：路由查询与报文重写

IP包进入table 20后，按目的IP查找路由。我的实现里直接用/32主机路由，等价于把"同网段内主机MAC表"显式铺出来：

bash复制# 去往192.168.2.10的包：源MAC改成p2侧网关MAC，目的MAC改成ns2的MAC，TTL减一，从veth2出去
ovs-ofctl -O OpenFlow13 add-flow br0 "table=20,priority=400,ip,nw_dst=192.168.2.10/32 actions=mod_dl_src:02:00:00:00:02:02,mod_dl_dst:02:00:00:00:02:02,dec_ttl,output:veth2"

# 去往192.168.1.10的包：反向对应
ovs-ofctl -O OpenFlow13 add-flow br0 "table=20,priority=400,ip,nw_dst=192.168.1.10/32 actions=mod_dl_src:02:00:00:00:01:01,mod_dl_dst:02:00:00:00:01:01,dec_ttl,output:veth1"

# 默认丢弃
ovs-ofctl -O OpenFlow13 add-flow br0 "table=20,priority=0,actions=drop"

这里有几个设计决策需要解释：

第一，为什么用/32而不是/24网段路由？如果用nw_dst=192.168.2.0/24，那么去往192.168.2.0/24里的任何IP都会被重写成ns2的MAC，从veth2出去。如果这个网段只有ns2一台主机，倒也能通，但一旦网段内部有多台机器，你没法用一条规则区分不同的目的主机MAC。路由器的标准行为是"目的IP在直连网段内，就ARP解析具体主机"，而流表没有现成的ARP解析流程。用/32硬编码是最直观、最不容易出错的方案。

如果你确实想在同一网段内支持多台主机，那就要为每台主机配一条/32规则，或者动态用learn动作加规则，这就复杂了。我这里只演示最核心的机制。

第二，mod_dl_dst:02:00:00:00:02:02的本质是"下一跳MAC"。在真实路由器中，这一跳通常是目的主机的MAC，因为目的网段是直连网段；如果目的网段经过多层路由，这里应该填下一跳路由器的MAC，而不是最终目的主机的MAC。理解"下一跳"和"最终目的"的区别，是理解路由重写机制的关键。

第三，dec_ttl一定要放在mod_dl_*后面还是前面？从语义上讲，ttl递减是三层处理，MAC重写是二层封装，顺序不影响最终结果，但习惯上我会先重写MAC再做TTL处理。有一点需要注意：dec_ttl动作在OpenFlow 1.0里可能不存在，所以命令里我统一加-O OpenFlow13指定协议版本。

4.4 一条龙配置脚本

把上面所有命令整理成一个脚本，方便复现：

bash复制#!/bin/bash
# L3流表一键配置脚本，适用于本文实验拓扑
set -e

OVS_CMD="ovs-ofctl -O OpenFlow13"

# 清空旧流表
$OVS_CMD del-flows br0

# Table 0：入口分流
$OVS_CMD add-flow br0 "table=0,priority=100,arp actions=resubmit(,10)"
$OVS_CMD add-flow br0 "table=0,priority=100,ip actions=resubmit(,20)"
$OVS_CMD add-flow br0 "table=0,priority=0,actions=drop"

# Table 10：ARP代答
$OVS_CMD add-flow br0 "table=10,priority=200,arp,arp_op=1,arp_tpa=192.168.1.1 actions=load:2->NXM_OF_ARP_OP[],move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],move:NXM_OF_ARP_SHA[]->NXM_OF_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:02:00:00:00:01:01->eth_src,set_field:02:00:00:00:01:01->arp_sha,set_field:192.168.1.1->arp_spa,IN_PORT"
$OVS_CMD add-flow br0 "table=10,priority=200,arp,arp_op=1,arp_tpa=192.168.2.1 actions=load:2->NXM_OF_ARP_OP[],move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],move:NXM_OF_ARP_SHA[]->NXM_OF_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:02:00:00:00:02:02->eth_src,set_field:02:00:00:00:02:02->arp_sha,set_field:192.168.2.1->arp_spa,IN_PORT"
$OVS_CMD add-flow br0 "table=10,priority=0,actions=drop"

# Table 20：路由查询与转发
$OVS_CMD add-flow br0 "table=20,priority=400,ip,nw_dst=192.168.2.10/32 actions=mod_dl_src:02:00:00:00:02:02,mod_dl_dst:02:00:00:00:02:02,dec_ttl,output:veth2"
$OVS_CMD add-flow br0 "table=20,priority=400,ip,nw_dst=192.168.1.10/32 actions=mod_dl_src:02:00:00:00:01:01,mod_dl_dst:02:00:00:00:01:01,dec_ttl,output:veth1"
$OVS_CMD add-flow br0 "table=20,priority=0,actions=drop"

配置完成后，用下面命令确认流表已经下发：

bash复制ovs-ofctl -O OpenFlow13 dump-flows br0

正常会看到6条规则（table 0三条、table 10三条、table 20三条）。

5. 验证它们到底通没通：ping、抓包、trace三个角度

5.1 实测结果与ARP应答过程

流表配好后，从ns1发起Ping：

bash复制ip netns exec ns1 ping -c 3 192.168.2.10

我这边实测输出的效果是：

code复制PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data.
64 bytes from 192.168.2.10: icmp_seq=1 ttl=63 time=0.821 ms
64 bytes from 192.168.2.10: icmp_seq=2 ttl=63 time=0.604 ms
64 bytes from 192.168.2.10: icmp_seq=3 ttl=63 time=0.750 ms

第一次能通，说明ARP代答和路由转发都正常工作。留意到TTL字段是63，原始TTL是64，正是经过OVS这"一跳"被dec_ttl递减后的结果。这其实是个很好的佐证：说明流量确实走了流表的三层处理，而不是通过某种二层捷径。

如果想更清楚地看到ARP是怎么被代答的，在ns1里抓包：

bash复制ip netns exec ns1 tcpdump -i veth1_p -nn arp or icmp

发起一次ping后，你会看到类似这样的报文序列：

code复制ARP, Request who-has 192.168.1.1 tell 192.168.1.10, length 28
ARP, Reply 192.168.1.1 is-at 02:00:00:00:01:01, length 28
IP 192.168.1.10 > 192.168.2.10: ICMP echo request, id 1, seq 1, length 64
IP 192.168.2.10 > 192.168.1.10: ICMP echo reply, id 1, seq 1, length 64

这个输出刚好验证了table 10的ARP应答逻辑：请求方问192.168.1.1，应答方给出了网关MAC。收到应答后ns1才继续发ICMP包。整个过程顺序清晰。

5.2 用ofproto/trace做报文级仿真

Ping通只是最终结果，如果想确认每个包里哪条流表规则命中、执行了什么动作，ovs-appctl ofproto/trace是排障神器。它能模拟一个数据报文在OVS里的完整旅程，不会真正发包。

用一条从ns1发往ns2的ICMP报文做测试：

bash复制ovs-appctl ofproto/trace br0 'in_port=veth1,dl_src=02:00:00:00:01:01,dl_dst=02:00:00:00:01:01,dl_type=0x0800,nw_src=192.168.1.10,nw_dst=192.168.2.10,nw_proto=1,nw_ttl=64'

输出的关键片段大致是：

code复制Flow: arp, metadata=0, in_port=veth1, ...
Rule: table=0 priority=100, ip actions=resubmit(,20)
...
Rule: table=20 priority=400, ip,nw_dst=192.168.2.10/32 actions=mod_dl_src:02:00:00:00:02:02,mod_dl_dst:02:00:00:00:02:02,dec_ttl,output:veth2
Final flow: ..., nw_ttl=63, ...
Datapath actions: set(eth(src=02:00:00:00:02:02,dst=02:00:00:00:02:02)), set(ttl(63)), veth2

看这几个地方就够了：

• 开头显示Flow:的内容，确认模拟报文和实际请求匹配；
• Rule:行显示了每一级table命中的具体规则；
• 最后Datapath actions:会展示内核数据路径真正要执行的动作列表。

如果trace里走到某一步突然变成drop，或者输出里看不到output:veth2，那就说明对应流表匹配有问题，对照着改就行。

5.3 容易翻车的几个细节点

实验做完后，我把自己踩过的和帮别人排查时遇到的高频问题整理一下：

第一个坑：ARP应答字段顺序错乱。这个前面提过，先move再set_field，一旦顺序反了，应答包的目的MAC全变。判断方法很简单：ns1里抓包看到ARP Reply的is-at地址正确，但ping还是超时，多半是以太网目的地址被写错了。

第二个坑：只配了table 20的正向规则，忘了回程。A到B通了，B到A丢包，几乎都是这个原因。我习惯在配完所有流表后，分别模拟正反两个方向的数据包trace一遍，确保两个方向都有明确动作。

第三个坑：OpenFlow版本不一致。dec_ttl、set_field这些操作在低版本协议里可能不被支持。有些新版ovs-ofctl默认使用的协议版本已经足够高，但为了可移植性，命令里最好都加-O OpenFlow13。如果不加，某些旧字段可能报错"field not found"或者静默失败。

第四个坑：网桥网卡没up。数据包进不了OVS，什么流表都是空谈。排查时先ovs-vsctl show和ip link show看端口状态。

第五个坑：命名空间路由没配。ns1里如果忘记加默认网关，ping的时候会直接报错"Network is unreachable"，根本到不了ARP阶段。

6. 从实验台到生产网：流表L3在Neutron DVR里的真实位置

6.1 纯流表方案的适用边界

做完这个实验，我相信你已经感受到了纯流表L3的魅力和代价。魅力在于它能把路由器的行为拆到肉眼可见的程度，代价是所有的路由、ARP、TTL逻辑都变成了一条条静态规则。这个方案在以下场景比较合适：

• 拓扑稳定、网段和MAC地址基本不变的小型虚拟网络；
• 边缘网关、实验室环境、IoT边缘网关上做固定路径转发；
• 想深入理解OpenFlow和SDN数据面的人做教学实验。

一旦遇到这些情况，纯流表就会吃力：多租户环境下需要成千上万条规则，规则之间互相覆盖；需要动态路由协议（OSPF/BGP）接入；需要NAT、DHCP、安全组等复杂功能；无线动态MAC变化频繁。此时要么回到netns路由器，要么引入SDN控制器。

6.2 DVR中OVS流表和qrouter的分工

提到生产环境，就绕不开Neutron DVR（分布式虚拟路由器），而热词里的"ovs agent l3"正是玩这个的。DVR的设计思想其实很美：把原来的集中式路由器（qrouter命名空间）放到每个计算节点上，让东西向流量从源节点直接转发到目的节点，不再绕路到网络节点。

但DVR并不是完全抛弃流表，它恰恰是"netns + 流表"的混合体。以东西向流量为例：

1. 虚拟机发出的数据包到达br-int，OVS流表会识别目的MAC是不是qrouter的MAC。
2. 如果不是，按二层转发或者走隧道到远端节点。
3. 如果是要路由的包，流表会把包送到本节点的qrouter命名空间，由内核协议栈完成真正的IP路由、NAT等复杂处理。
4. qrouter处理完后把包交回OVS，流表再根据目的节点打上相应的tunnel encapsulation，发到对端。

换句话说，DVR里的OVS流表负责"导流"和"隧道封装"，而qrouter负责"路由决策"和"复杂网络功能"。两者分工明确，扬长避短。我在这篇文章里用纯流表实现L3，本质上是把qrouter内核协议栈做的那部分逻辑硬生生用OpenFlow重新写了一遍——这个练习对理解DVR为什么要在br-tun和br-int上配置那么多流表极有帮助，因为你在生产环境里看到的每一条规则，都能在这套基础实验里找到对应的动作原型。

说实话，当时我在生产环境里看到ovs agent l3下发那几十条流表时觉得云里雾里，做完这个最小实验后，再看那堆规则就亲切多了。很多流表无非就是table=0里先把流量分类，然后resubmit到对应表，遇到router的流量就用strip_vlan和mod_dl_src做端口收敛，本质上和我写的table 20里的mod_dl_src/output是一回事，只不过规模大了几个数量级，而且多了隧道、VLAN等封装逻辑。

最后再分享一个实测后养成的习惯：每次配完L3流表，我都会顺手把两个方向的ofproto/trace各跑一遍，确认输出里的Datapath actions是自己预想的样子，再去敲ping命令。这一步能省掉一半的排障时间——亲眼看到数据包在规则间"走"一遍，往往比看抓包更快理解问题出在哪一环。