H3C策略路由(PBR)实验：源地址分流与多下一跳主备切换详解

前阵子我搭了一套 H3C 策略路由（PBR）实验环境，把基于源地址分流、多下一跳备份这两件事完整跑了一遍。做完之后最大的感受是：PBR 的配置命令量不大，真正的难点在于“什么场景该用它”和“怎么证明报文真的按你的想法走了”。文章里我就按实际操作顺序来写，从拓扑设计、ACL 匹配、策略下发，到链路中断后的自动切换验证，全部交代清楚。适合已经会静态路由、想搞明白多出口选路的兄弟，也适合准备网络认证实验或者面试中 PBR 相关话题的人。

传统路由表也好，动态路由协议也罢，选路依据只有一个：目的地址。可现实中很多需求是“某些人、某些应用走这条线，其他走那条线”。这就是 PBR 的用武之地。它让路由器在查路由表之前，先按你定义的策略做一次判断，把流量引到指定下一跳或出接口。

1. 传统路由表解决不了的选路问题

1.1 一个典型的多出口需求

假设你是公司出口路由器管理员，内网有两个网段：10.1.1.0/24 和 10.1.2.0/24。你手上有两条上联链路，分别接到两个运营商设备上。这时候老板提需求：10.1.1.0/24 的流量走第一条链路，10.1.2.0/24 的流量走第二条链路。

如果只用传统静态路由，你会怎么配？最朴素的做法是写两条默认路由，分别指向两个不同下一跳。但这样一来，两条路由是等价负载均衡关系，设备会把去往同一个目的地的不同报文哈希到不同链路上。也就是说，10.1.2.x 的某个用户访问某个网站时，第一个包可能走了链路 A，第二个包可能走了链路 B，完全不受你控制。

你当然可以靠 NAT 转换源地址来变相实现，比如给不同网段做不同出接口的 NAT，但这种方式并不总是好用。尤其当你还希望按照“目的端口是 TCP 80 的流量走专线”这种更细粒度条件来选路时，传统路由表就彻底没辙了。

1.2 PBR 的本质：先判策略，再查路由表

PBR（Policy-Based Routing，策略路由）做的事情其实很朴素：报文从某个接口进入设备后，先不看目的地址，而是先按你定义的策略规则匹配。匹配上了，就直接按策略里指定的下一跳或出接口转发；如果没匹配任何策略，或者策略里指定的转发路径不可用，才回到普通路由表继续走常规流程。

这个“先判策略，再查路由表”的顺序非常关键。它意味着 PBR 的优先级天然高于任何路由协议和静态路由。普通路由表是通过目的地址去“查”，PBR 是通过报文的源地址、协议类型、端口、报文长度等特征去“筛”。前者是全局一张表，后者是可以灵活叠加的规则链。

我经常用一个生活类比来解释：普通路由就像小区只有一个大门，所有人都从同一个门口进出；PBR 就像门卫在门口检查，按你从哪栋楼来、门禁卡是什么类型，把你安排到不同的车道或出口。

1.3 学 PBR 之前需要什么基础

建议你先掌握这几个前置技能再做实验：接口 IP 配置、静态路由、ACL 基本规则、ping 和 tracert 的基本用法。懂一点 NAT 更好，因为真实出口场景里 PBR 通常和 NAT 配合使用。如果你已经能独立配置一台路由器连接两个网段并实现互通，那 PBR 就只是在这套基础上加几段配置的事情。

实验环境方面，有一台能跑 H3C 设备命令行界面的模拟器就够了，真机当然更好。我这次用的是三台路由器加两台 PC 的拓扑，不算复杂，但已经能把 PBR 的核心机制完整呈现。

2. 实验拓扑与需求拆解

2.1 拓扑结构和地址规划

我画的拓扑是这样的：R1 是出口路由器，两个内网网段分别挂在它的两个接口下面；R2 和 R3 模拟两个不同的上联出口设备。每台路由器再加一个 Loopback 地址作为测试目标，这样能直观地判断流量到底走到了哪一侧。

具体接口和地址规划如下表：

R1 上除了接口地址，我只配了一条默认路由，指向 R2：ip route-static 0.0.0.0 0.0.0.0 10.1.3.2。这样做的目的是让“没有 PBR 时所有流量都走 R2”成为基准行为，后面加了 PBR 才能看出对比效果。

R2 和 R3 上需要配置回程路由，不然 PC 的 ping 包到达后，路由器不知道回包给谁。R2 上写两条静态路由：去 10.1.1.0/24 和 10.1.2.0/24 的下一跳都是 10.1.3.1。R3 上也写两条类似的静态路由，下一跳指向 10.1.4.1。

2.2 本次实验的两条核心需求

我给这次实验定了两个目标。第一个是源地址分流：PC-A 的流量固定走 R2，PC-B 的流量固定走 R3。第二个是链路主备切换：当 R1 到 R3 的链路不可达时，PC-B 的流量能自动切到 R2 这条链路上，R3 恢复正常后又能切回去。

这两个需求非常贴近真实生产场景。源地址分流常用于多运营商线路负载分担，把不同办公区域的用户分配到不同出口；主备切换则解决了“链路故障或质量劣化后流量怎么办”的问题。H3C 的 PBR 实现中，同一个策略节点下可以配置多个apply next-hop，使用时会按照配置顺序依次尝试，这个机制正好可以用来做主备切换。

2.3 先理清 PBR 的生效位置

配置 PBR 之前，有一个原则必须植入脑子：PBR 只对从指定接口进入的报文生效，它是在入接口上作用。很多初学者第一次配置总喜欢把策略绑在出接口上，结果流量从入接口进来后根本不会匹配策略，排错半天都找不到原因。

拿我们这个拓扑来说，PC-B 的流量是从 R1 的 G0/0/1 接口进入的，所以 PBR 要下发在 G0/0/1 这个入接口上。如果强行把同一策略下发到 G0/0/2 或 G0/0/3 这种出接口上，那只有从这些接口进入的流量会被匹配，而内网用户从 G0/0/1 进来的流量完全不受影响。

这里所说的“入接口”是站在流量进入设备的方向看的。同一台路由器上，不同接口进来的流量可以被不同策略处理，策略之间互不干扰。这也是 PBR 比全局路由策略更灵活的原因之一。

3. H3C PBR 配置全流程：逐条拆解

3.1 第一步：把 ACL 规则写好

PBR 的匹配条件通常挂在 ACL 上，所以先要定义好 ACL。我用的是高级 ACL 3000，匹配源地址 10.1.2.0/24。这里有个细节初学者很容易栽跟头：ACL 里写的是反掩码（通配符），不是子网掩码。匹配 10.1.2.0/24，应该写0.0.0.255，而不是255.255.255.0。

acl advanced 3000 rule 5 permit ip source 10.1.2.0 0.0.0.255

ACL 规则编号我习惯从 5 开始，后面可以插入 10、15 这样的编号，留足扩展空间。如果一开始就用 1、2、3 这样的连续编号，将来想在某条规则之间插一条新的规则，就会非常别扭，要么删除重建，要么用更大的编号重新排列。

ACL 默认规则是 deny。如果建了一个 ACL 里面只有 deny 规则，或者根本没写 permit，那 PBR 节点永远匹配不到流量。所以写完 ACL 后，可以先单独用命令查看一下 ACL 内容，确认规则方向没有写反。

3.2 第二步：定义策略路由节点

H3C 的策略路由配置核心是policy-based-route。我给这个策略起名pbr-demo，节点号用 10。节点号的作用和 ACL 规则编号类似，数值越小越优先匹配。

policy-based-route pbr-demo permit node 10 if-match acl 3000 apply next-hop 10.1.4.2 apply next-hop 10.1.3.2

这段配置的含义是：如果报文匹配 ACL 3000，也就是源地址属于 10.1.2.0/24，那么优先把下一跳指定为 10.1.4.2（R3）。如果 10.1.4.2 不可达，就尝试第二个下一跳 10.1.3.2（R2）。

多配置几条apply next-hop就是主备切换的核心。系统会按配置顺序依次检查每个下一跳是否可用，第一个可用就直接用，不可用才尝试下一个。如果所有可用的下一跳都不存在，则进入普通路由表流程。这个机制比写脚本去探测链路再改路由表优雅得多。

如果你不想用下一跳，而是想强制指定出接口，可以改成apply output-interface GigabitEthernet0/0/3。不过这种写法有一个明显的副作用：它只认接口，不认对端地址。下一跳可达但接口因为某种原因 down 了，它就会失效；而接口 up 但远端设备已经不可达，它仍会把报文硬塞出去。所以大多数场景我更推荐用apply next-hop。

3.3 第三步：在接口上应用策略

定义好策略后，必须把它下发到入接口才生效。PC-B 的流量从 R1 的 G0/0/1 进入，所以在这里应用：

interface GigabitEthernet0/0/1 ip policy-based-route pbr-demo

然后我又做了第二个实验：PC-A 的流量也想固定走 R2。虽然 R1 默认路由本来就指向 R2，但为了验证“策略路由优先于普通路由表”这一点，我给 PC-A 的入接口也应用了一个策略节点，匹配源 10.1.1.0/24，apply next-hop 10.1.3.2。此时策略没有改变实际路径，但可以通过统计计数确认它确实被命中。

policy-based-route pbr-demo permit node 20 if-match acl 3001 apply next-hop 10.1.3.2

接口下发那条命令，有两点值得注意。一是策略名称不能写错，设备不会报错提示“该策略不存在”，但如果策略名对不上，接口会静默不加载。二是同一个接口只能应用一个策略，如果重复应用，后配置的会覆盖前面的。

3.4 第四步：查看策略与命中情况

配置完成后，用查看命令确认策略已经存在、并且和接口正确绑定。H3C 常用的有三条命令。

display ip policy-based-route policy pbr-demo display ip policy-based-route setup display ip policy-based-route statistics

第一条用来查看策略里定义的节点、匹配条件和 apply 动作。第二条查看各接口生效的策略绑定关系。第三条最关键，用来查看每个策略节点被命中多少次，这是我判断流量是否真正走到 PBR 的最直接证据。

如果你在查看统计之前希望计数从零开始，可以先用reset ip policy-based-route statistics清空，然后再发测试流量，这样看到增长的数字就有说服力了。

4. 实验结果验证：从通断测试到链路切换

4.1 不出意外的话，先看到传统路由的效果

在应用 PBR 之前，我先从 PC-B 做了两个 ping 测试：ping 2.2.2.2 和 ping 3.3.3.3。因为 R1 只有一条默认路由指向 R2，所以 PC-B 的所有流量都会被送到 R2。结果就是 ping 2.2.2.2 能通，因为 2.2.2.2 就在 R2 上；ping 3.3.3.3 不通，因为 R2 根本不认识 3.3.3.3，也没有去往该地址的路由，直接丢弃。

这个结果非常重要，它证明了没有 PBR 时所有流量确实都走 R2，而且 R2 的行为可以作为参照，帮我们判断后续流量是不是真的被 PBR 改变了路径。

4.2 应用 PBR 后，看命中计数和 R3 接口

把pbr-demo下发到 G0/0/1 后，我重新在 PC-B 上 ping 3.3.3.3，结果变成“通”了。这说明流量被成功引导到了 R3。为了确认这一点，我执行了：

reset ip policy-based-route statistics

然后在 PC-B 上连续发了一批 ping 包，再次查看统计，节点 10 的命中计数明显增长。同时在 R3 上查看 ICMP 调试，能看到来自 10.1.2.1 的请求反复到达。R2 上则没有任何来自 PC-B 的 ICMP 请求产生。

这一步验证了 PBR 的强制转发能力：即使目的地址 3.3.3.3 和 R3 是同一台设备，这个 ping 能通的关键也不在于“路由表本来就知道怎么走”，而在于 PBR 把报文主动交到了 R3 手里。如果 PBR 没有生效，报文到 R2 就被丢掉了。

4.3 模拟链路故障：shutdown 出一个主备切换现场

现在做第二个实验。PC-B ping 2.2.2.2，按前面分析，由于 PBR 节点 10 的第一条apply next-hop 10.1.4.2是可达的，所以报文会被强制送到 R3，而 R3 不认识 2.2.2.2，ping 会失败。这正好用来验证 PBR“只认源匹配、不看目的地址”的强制特性。

然后我在 R1 上把连接 R3 的接口 shutdown，模拟链路故障：

interface GigabitEthernet0/0/3 shutdown

此时 10.1.4.2 这个下一跳在 R1 的直连路由表中已经不存在了，PBR 节点 10 的第一条apply next-hop失效，设备自动切换到第二条apply next-hop 10.1.3.2。PC-B 再次 ping 2.2.2.2，结果变成“通”了。

恢复链路：

interface GigabitEthernet0/0/3 undo shutdown

稍等几秒，再次从 PC-B ping 2.2.2.2，又不通了，因为第一条下一跳又变为可用，流量重新被切回 R3。这个“链路断开自动切换、恢复后自动回切”的过程，就是很多高可用组网里想要的 behavior。H3C PBR 用两条apply next-hop就实现了，没有依赖额外脚本，也没有人工干预。

这里要提醒一点：这个实验里我使用的是测试环回地址，所以切换前后 ping 的通断结果恰好是反直觉的。真实场景中两个出口后面通常都是相同的互联网，目的地址对两台出口设备都是一样可达的，所以你看不到“从通变不通再变通”的戏剧性现象，但原理完全一致。通过这个刻意设计，你能更深刻地理解 PBR 是怎么样“强制改道”的。

4.4 扩展：本地策略路由要注意

实验做到一半，我想测试一下 R1 自身的流量行为，比如从 R1 ping 3.3.3.3。结果发现它仍然走默认路由送往 R2，策略没有生效。原因很简单：PBR 作用于转发平面的报文，路由器自己产生的报文不经过入接口的报文接收流程，所以无法被普通 PBR 匹配。

如果确实需要让本机流量也受策略控制，H3C 提供了本地策略路由命令，全局下发即可：

ip local policy-based-route pbr-demo

配置本地策略路由后，R1 自己主动发起的流量也会先匹配策略。实际运维中，有时会用这种方式让设备的管理流量走特定链路，或者让网管地址从指定出口出去。不过要小心，本地策略路由会把所有本机发出的流量都纳入策略判断，配置不当可能影响 SSH 登录、路由协议报文等关键流量，建议慎用。

5. 常见问题与排查经验实录

5.1 策略没生效？先按这三个点排查

我在模拟器和真机上踩过不少 PBR 的坑，总结下来绝大多数“没生效”都出在三个地方。第一个是策略绑定错了接口。PBR 必须绑定在流量的入接口上，很多同事第一次配置总是下意识绑在出接口，结果怎么测都不匹配。判断方法是看display ip policy-based-route setup，确认接口下发的策略名称和实际策略名称一致。

第二个是 ACL 根本就没匹配到。ACL 默认是 deny，如果规则写错反掩码，比如把0.0.0.255写成255.255.255.0，ACL 会认为是在匹配一个奇怪的范围，流量直接不命中。写完 ACL 后花十秒钟确认一下规则是最值得的投资。

第三个是真匹配上了，但没有可用的转发动作。比如策略里只有if-match没有apply，或者apply next-hop指向了一个不可达地址、而该地址又不在一张可达路由表中。这种情况下设备无法产生有效的转发动作，只能回退到普通路由表，看起来就像“策略没生效”。

排查时最有效的命令是display ip policy-based-route statistics。如果命中计数不增长，说明流量根本没走到策略这条路；如果计数增长但行为没变化，那问题大概率出在apply动作本身不可用。

5.2 本机访问外网不受 PBR 控制

这个问题我前面提过，但它的出现频率实在太高，值得单独再列一条。某天你在出口路由器上配好了 PBR，想验证效果，直接在路由器上用 ping 命令发起测试，结果发现流量没按策略走，你可能会怀疑配置有问题。实际原因并不是配置出错，而是 PBR 不处理本机发出的报文。

验证 PBR 效果的时候，一定要用 PC 去测试，或者用扩展 ping 指定源地址，让报文从某个内网接口进入设备。比如ping -a 10.1.2.1 3.3.3.3，强制用 PC-B 所在网段地址作为源发起 ping，这样流量才会经过入接口并被 PBR 处理。如果必须让本机流量也走策略，再考虑ip local policy-based-route。

5.3 apply next-hop 和 apply output-interface 怎么选

很多人在配置时纠结到底用哪个。我的经验是优先用apply next-hop。它语义清晰：指定一个下一跳 IP，设备会先确认这个下一跳是否可达，不可达就尝试下一个下一跳。这个“确认”机制使得多下一跳备份天然可用。

apply output-interface则更“暴力”，它直接指定从哪个物理接口发送报文，不关心对端地址是否正常。某些场景下这很有用，比如你希望即使路由表没有对应路由，也强制将匹配报文从某个接口送出去。但一旦接口 down，或者对端设备已经故障但接口还 up，它就会把报文送进黑洞。所以说到底，apply next-hop更安全，更适合做主备；apply output-interface更适合在确定链路永远可达的场景中使用。

还有一个细节：如果同时配了多条apply next-hop和一条apply output-interface，设备会按什么顺序执行？实际行为取决于设备版本，但最稳妥的设计是不要同时混用两种 apply 方式，避免出现不可预期的优先级差异。把同一个节点里的多个下一跳当成“候选列表”反而好理解。

5.4 ACL 顺序和节点编号是隐形的坑

PBR 策略里面，多个if-match条件是“与”的关系，必须全部满足才会执行apply。但很多人会忽略：一个策略下有多个节点时，报文是按节点编号从小到大逐个尝试的，一旦某个节点匹配成功，就不再继续往后匹配了。所以节点的先后顺序、每个节点里的 ACL 是否精确，会直接决定流量会不会被前面的节点“截胡”。

我在实验中把节点 10 留给 PC-B，节点 20 留给 PC-A，中间留了 10 个编号的间隔，就是担心以后要插新节点。实际项目中，如果有人把节点 10 写成一个很宽泛的匹配条件，比如匹配了整个 10.1.0.0/16，那后面的节点 20 可能永远没有机会执行。每次改动策略后，最好都看一眼统计计数，确认预期的节点在增长，而不是更靠前的某个节点在增长。

另一个细节是 ACL 规则的用途。同一个 ACL 既可以被 PBR 引用，也可以被 QoS、防火墙策略引用，修改 ACL 规则会影响所有调用它的模块。实验环境里无所谓，生产环境动 ACL 前必须确认影响面，最好新建独立 ACL 给 PBR 专用，避免“改了一条规则，安全策略也跟着变”的连锁事故。

最后再分享一点我的实操体会

PBR 这套东西，配置命令就那么几条，背下来不难，但真正值钱的是对流量行为的理解。我这次实验里刻意设计了“ping 2.2.2.2 从通变不通、再由不通变通”的验证环节，就是想把 PBR 的“强制改道”特性深深地刻在脑子里。很多人学 PBR 只会在静态配置里敲命令，从来没有亲手 shutdown 过一条链路，看流量切换到底需要多久、统计计数怎么变化。我建议你做实验时一定要走到这一步，把链路中断和恢复的过程反复做几遍。

后续如果想继续往深了玩，可以把 PBR 和 NQA 联动，用 NQA 探测链路质量，再结合 Track 机制，实现不光是“接口级不可达”才切换，而是“链路质量变差”也能自动切换。那已经接近生产环境高可用方案的复杂度了。另外，把 PBR 和 NAT 放在一起做实验也很有意思，能更完整地模拟真实出口场景。希望这篇文章能帮你把 PBR 的关键点一次吃透，少走几步弯路。