H3C策略路由PBR双出口实验：配置、验证与排错全指南

做网络的人早晚会撞上这样一个需求：内网有两条出口链路，领导指定“财务部门的流量必须走专线，其他上网流量走普通宽带”，然后你觉得这很简单，在出口设备上多写几条静态路由不就完事了吗？真正敲完命令你会发现，路由表只认目的地址，它根本不在乎这个包是从哪个网段来的。这种时候，能派上用场的正是H3C设备上的策略路由（PBR）。

下面我带着你用HCL模拟器完整做一遍H3C PBR双出口实验。从拓扑怎么搭、ACL怎么匹配、策略绑在哪个接口，到验证时怎么确认“流量真的按你的意愿走了”，以及我踩过的几个典型坑，都会拆开讲。想学H3C路由交换、备考相关认证，或者打算在现网里用策略路由做选路的工程师，这篇可以直接照着操作。

1. PBR到底要解决什么问题：为什么查路由表不够用

1.1 传统路由的查表逻辑，以及它的三个盲区

路由器转发报文的核心动作只有一个：查路由表，按目的IP做最长匹配，决定出接口和下一跳。这个逻辑简洁、高效，但也注定它天生有盲区。

盲区一是“只认目的地，不认来源”。你去访问同一个公网IP，不管你坐在财务办公室还是普通工位，路由器看到的目的地址都一样，它就会把你俩一视同仁地送到同一条链路。盲区二是“不认协议和端口”。路由器查表时，根本不关心你是HTTP流量、VoIP流量还是视频会议流量，它只关心目的IP在哪。盲区三是“没有业务视角”。专线、普通宽带、教育网线路放在那里，路由表只能按目的网段去匹配，做不了“这批人走这条、那批人走那条”的精细控制。

我习惯用一个类比来理解PBR的价值：普通路由像所有人都按目的地导航，不管你是步行还是开车，都给你导同一条路；PBR则像调度中心，提前根据你的身份、需求指定你必须走哪座桥、哪条快速路。

1.2 两个最容易触发PBR需求的实际场景

第一个场景就是开篇说的源地址分流。办公网里划了多个业务网段，财务系统要访问银行专线，视频会议系统需要走独立的优质链路，普通员工上网走宽带出口。不同业务网的源地址不同，适合用源IP匹配来区分，这是PBR最经典的应用方式，本文实验就围绕它展开。

第二个场景是多出口负载分担。两条线路带宽不一样，如果只靠等价路由做ECMP，设备按目的地址哈希分流，同一个源IP的会话可能一会儿走A线、一会儿走B线，对某些应用不友好。用PBR按源网段或按报文属性拆分，可以把一部分用户固定送到A线，另一部分送到B线，实现更可控的分担。

顺带提一句，PBR不只存在于出口路由器上。内部核心交换机、防火墙前后、专线接入层都可能有类似需求，H3C的交换机上也支持PBR，只是配置入口和接口形态略有区别。这篇文章以路由器实验为例，底层逻辑是通用的。

1.3 先分清两个“策略”：PBR和Route-Policy不是一回事

H3C里有两个名字带“策略”的东西，一个是策略路由PBR，一个是路由策略Route-Policy。很多人在这一步就乱掉了，其实分工很明确。

一句话记忆：路由策略是决定“路由表长什么样”，策略路由是决定“数据包走哪条路”。前者管控制平面，后者管转发平面。考试和现场排障都爱考这个区别，务必记牢。

2. 实验环境准备与拓扑设计：双出口分流场景怎么搭

2.1 模拟器选择与启动时的坑

这个实验用HCL（H3C Cloud Lab）就能完成，不需要真机。模拟器里选一台MSR36-20路由器作为核心，再开两台路由器模拟两个不同的运营商出口。PC可以用模拟器自带的PC，也可以直接用主机加Loopback模拟，看个人习惯。

HCL启动时有个经典问题：如果你的电脑启用了Hyper-V，或者VirtualBox版本和HCL自带的组件冲突，模拟器可能一直卡在启动界面。常见的处理办法是关闭Hyper-V相关功能，或者换用与HCL兼容的VirtualBox版本。如果还是起不来，检查一下设备是否出现红色标记，右键查看控制台，接口一定要确保链路是连通的。

还有一点，模拟器里路由器接口默认是不做特殊限制的，但如果你在真机上做实验，接口经常要手动undo shutdown，养成习惯总没错。

2.2 拓扑设计与IP编址表

我把拓扑设计成一个典型的小型办公网出口：

• R1：核心出口路由器，运行PBR。
• R2：模拟运营商ISP1，提供一个外网服务地址。
• R3：模拟运营商ISP2，也提供一个外网服务地址。
• PC1：业务网段1，要求强制走ISP1。
• PC2：业务网段2，普通上网流量，默认走ISP2。

链路关系用文字描述就是这样：PC1和PC2通过一台傻瓜交换机接到R1的G0/0/0口；R1的G0/0/1口连接R2；R1的G0/0/2口连接R3。R2和R3各有一个Loopback地址，当作外网服务器来用。

这个拓扑里最关键的设计点是：R1的默认路由指向ISP2（R3），而R2提供的2.2.2.2是“只有R2知道”的地址。这样一来，在没有PBR的情况下，PC1访问2.2.2.2必然失败，加了PBR之后成功，就能直观证明PBR起作用了。

2.3 基础配置：先把网络调通，再谈策略

先配R1的接口地址：

# R1 interface GigabitEthernet0/0/0 ip address 192.168.10.254 255.255.255.0 ip address 192.168.20.254 255.255.255.0 sub undo shutdown interface GigabitEthernet0/0/1 ip address 192.168.12.2 255.255.255.252 undo shutdown interface GigabitEthernet0/0/2 ip address 192.168.13.2 255.255.255.252 undo shutdown

再配R2和R3：

# R2 interface GigabitEthernet0/0/1 ip address 192.168.12.1 255.255.255.252 undo shutdown interface LoopBack0 ip address 2.2.2.2 255.255.255.255 # R3 interface GigabitEthernet0/0/1 ip address 192.168.13.1 255.255.255.252 undo shutdown interface LoopBack0 ip address 3.3.3.3 255.255.255.255

然后是路由。R1默认走ISP2，R2和R3各自要有一条默认路由指回R1，否则回包回不来：

# R1 ip route-static 0.0.0.0 0.0.0.0 192.168.13.1 # R2 ip route-static 0.0.0.0 0.0.0.0 192.168.12.2 # R3 ip route-static 0.0.0.0 0.0.0.0 192.168.13.2

配置完以后，PC1能ping通网关192.168.10.254，PC2能ping通网关192.168.20.254，R1到R2/R3的互联地址也能通，基础环境就算准备好了。此时先别急着配置PBR，专门花一分钟做个对照测试：PC1去ping 2.2.2.2，结果是失败的。原因刚才说过了，R1默认把包交给R3，而R3不知道2.2.2.2在哪，于是又按默认路由丢回R1，两边反复打转直到TTL耗尽。请记住这个“不通”的初始状态，后面它就是你判断PBR是否生效的参照物。

3. 一步步配置策略路由：ACL匹配、策略节点与应用接口

3.1 用高级ACL把内网流量分类

PBR的第一步是把不同类型的流量认出来。这里用高级ACL按源地址分类，编号范围是3000到3999：

# R1 acl advanced 3000 rule 5 permit ip source 192.168.10.0 0.0.0.255 acl advanced 3001 rule 5 permit ip source 192.168.20.0 0.0.0.255

ACL命名编号可以和网段呼应，3000绑给192.168.10.0/24，3001绑给192.168.20.0/24，后面对照起来很方便。这里有个要点：PBR的if-match acl只会拿ACL里permit规则去匹配报文，如果你写的ACL全是deny，那PBR节点就永远匹配不上任何流量。这一点后面排错部分还会遇到，先记下。

3.2 PBR节点：匹配什么，去哪

接下来定义策略本体。在H3C上，PBR的配置结构是“策略名+节点号”，节点号决定匹配顺序，数字小的先匹配：

# R1 policy-based-route pbr1 permit node 10 if-match acl 3000 apply next-hop 192.168.12.1 policy-based-route pbr1 permit node 20 if-match acl 3001 apply next-hop 192.168.13.1

含义很直白：node 10负责匹配ACL 3000即源192.168.10.0/24的流量，命中后把下一跳指定为192.168.12.1，也就是ISP1侧的R2；node 20负责匹配ACL 3001，命中后把下一跳指定为192.168.13.1，交给ISP2侧的R3。

为什么用apply next-hop而不是apply output-interface？我的习惯是能用下一跳就用下一跳。下一跳的表达更接近真实转发语义：即使出接口发生变化，只要下一跳可达，策略依然有效。而写死出接口一旦链路重新规划、接口换掉，策略就得跟着改。

这里还可以思考一个问题：如果一条流量既匹配node 10又匹配node 20，最终会走哪？按节点号顺序，它会先在node 10命中并执行动作，直接结束匹配，根本不会轮到node 20。所以ACL的匹配范围要精确，避免策略之间打架。

3.3 绑在哪个接口：很多人第一反应就错了

策略定义好之后，必须应用到接口上才生效。最容易踩坑的就是这一步，绑定接口的方向选错，策略一点动静没有。

# R1 interface GigabitEthernet0/0/0 ip policy-based-route pbr1

注意：这里的接口是G0/0/0，也就是内网PC流量进入R1的那个口，而不是连接ISP1或ISP2的出口。PBR是在报文进入设备、查询普通路由表之前生效的，它作用于“入接口流量”。你把策略绑在G0/0/1或G0/0/2上，从内网进来的流量根本不会经过那个方向的检查，策略自然就成了摆设。

我见过有人反复检查ACL、检查策略命名，最后发现只是把策略放错了接口。这个方向问题是PBR排障里出现频率最高的一个，没有之一。

3.4 关于“兜底节点”和ACL的deny规则

有人可能会问，如果一条流量既没匹配ACL 3000，也没匹配ACL 3001，会怎样？答案是：它会按普通路由表正常转发，PBR不会拦截它。所以在这个实验里，如果存在其他网段的流量，它们会走R1默认路由指向的ISP2。

那要不要在策略末尾再加一个node 30做兜底？这要看你的需求。如果只想让“特定流量走指定路径”，其他流量保持现状，就不要加兜底节点。如果希望所有流量都被PBR管控，可以在策略末尾加一个没有if-match的节点，它默认匹配所有报文：

policy-based-route pbr1 permit node 30 apply next-hop 192.168.13.1

这个方式相当于把默认路由“搬”进了PBR里。但要注意，这种写法也存在隐患：一旦指定的下一跳不可达，流量就可能被丢掉，回到普通路由表的机制反而被绕过了。所以在现网里，兜底节点要配合链路探测一起用，这部分我会在第6章展开。

4. 验证流量是否真的走了指定链路：几条命令与一个容易误判的坑

4.1 ping通不代表PBR生效：实验要设计对照组

策略配完后，第一个直觉反应是赶紧ping一下。但我想先说一个观点：ping通本身并不能证明PBR生效了。

假设你的两条出口链路都能访问同一个目标公网IP，那不管流量走A线还是B线，ping结果都是通的。这种情况下，你只能确定“网络是通的”，根本分不清PBR有没有把流量引到预期的那条链路上。这就是为什么我在第2章特意把2.2.2.2设计成只有R2知道的目标：PBR配置前PC1访问2.2.2.2不通，配置后通了，才能形成有效的对照组。

所以在实验里，你至少要做三个层次的验证：

第一层，PBR配置前PC1访问2.2.2.2失败，PC2访问3.3.3.3成功，确认默认路由的工作状态。第二层，PBR配置后PC1访问2.2.2.2成功，说明源地址为192.168.10.0/24的流量确实被引到了R2。第三层，再用设备自带的统计命令确认命中次数，从转发平面的角度实锤PBR生效。

4.2 用命中统计和接口计数做实锤验证

H3C上查看PBR生效情况最常用的命令是：

# R1 display ip policy-based-route setup

这条命令会显示所有应用了PBR的接口、策略名、节点号以及命中报文数。如果策略真的在工作，能看到对应节点后的报文统计在增长。如果命中次数一直是0，说明流量根本没匹配到你的PBR节点，这时候就要怀疑ACL匹配规则或接口方向了。

另外还可以用接口流量计数辅助验证。先把接口计数器清零：

# R1 reset counters interface GigabitEthernet0/0/1 reset counters interface GigabitEthernet0/0/2

然后让PC1去访问2.2.2.2，再分别查看R1的G0/0/1和G0/0/2接口计数：

display interface GigabitEthernet0/0/1 display interface GigabitEthernet0/0/2

正常情况下，G0/0/1（连接R2）的出方向有报文增长，而G0/0/2（连接R3）基本没有来自PC1的流量。这个方法在真实设备和模拟器上都适用，尤其是当PBR配置在一个大流量的核心设备上时，接口计数可以快速帮你定位流量到底从哪个口出去了。

4.3 验证结果解读与对照表

把完整的验证结果整理成一张表，实验结束前逐项核对：

这套组合拳打下来，PBR是否生效就没有模糊空间了。最后记得在模拟器里再做一次保存配置，方便后续反复练习。

5. 回程路径的问题：PBR只管一半，对称路由必须自己保证

5.1 去程与回程为什么可能不对称

PBR只在报文进入设备的那一刻起作用，它不修改路由表，更不是源路由机制。它对去程的选择是强制的，但对手里的回包没有任何控制力。

用实验里的场景说：PC1访问2.2.2.2，去程在R1上被PBR强制送给了R2。当R2收到目的地址为192.168.10.1的回包时，它要做的是查自己的路由表。好在实验里R2只有一条默认路由，指向R1，所以回包能原路返回。

假如R2上配置了到192.168.10.0/24的两条路径，一条指R1，另一条指R3，那回包完全有可能从R3绕回来。去程一个方向，回程另一个方向，这在纯路由环境下有时还能通，但一旦中间隔着防火墙或NAT设备，状态化连接表会对这种不对称流量直接拦截，表现就是“去程看着发出去了，回包永远不来”。

所以做PBR实验或上线PBR方案时，回程路由必须单独检查一遍。PBR负责把流量送到指定出口，出口那边怎么把包送回来，是你的路由规划问题。

5.2 出口设备上的回程排查方法

在R2和R3上分别看一下路由表：

# R2 display ip routing-table # R3 display ip routing-table

预期结果是：R2和R3都有一条默认路由，下一跳指向R1的互联地址。这样从任何出口进来的回包，最终都会回到R1。如果R2上多出一条等价默认路由，或者指向了错误方向，回程就会出问题。

另外还可以在R1上用debug观察报文的进出方向：

# R1 terminal monitor terminal debugging debug ip policy-based-route

调试信息会显示PBR节点匹配的详细过程，包括报文从哪个接口进来、匹配到了哪个节点、动作是什么。看完记得关掉debug，避免日志刷屏影响模拟器性能。

6. 进阶与排错：PBR不生效的常见原因、NQA联动选路

6.1 我排PBR问题时先问自己的三个问题

PBR这个东西，配置行数不多，但出问题时的排查链条比较固定。我一般按顺序问自己三个问题。

第一个问题：策略绑对接口了吗？这里说的绑对，不仅要看是不是PBR要作用的那个设备，还要看是不是报文的入接口。很多人配了PBR后拼命看ACL，结果只是把策略挂在了出接口上，流量根本没被检查。

第二个问题：ACL匹配到目标流量了吗？用display acl acl-number查看ACL命中统计。如果ACL计数在增长，说明流量认得出来，问题出在PBR节点或动作上；如果ACL计数是0，那说明ACL里的rule写得不对，源地址反了、通配符写错，或者ACL根本没permit该匹配的网段。

第三个问题：PBR指定的下一跳可达吗？如果apply next-hop写的地址是个不可达地址，PBR匹配到了也白搭。先ping一下对端互联地址，确认链路本身没问题。

把这三个问题过一遍，八成以上PBR“不生效”的问题都能找到原因。

6.2 下一跳不可达时的行为差异与NQA/Track兜底

PBR匹配到报文后，如果指定的下一跳不可达，设备会怎么处理？我见过不少现场事故跟这个相关。在部分H3C版本上，匹配节点后的报文如果无法按apply动作转发，可能被直接丢弃，而不是“退回”到普通路由表。这就非常危险：你以为PBR只是在普通路由之外多加了一个选择，结果PBR匹配上了一条故障链路，流量直接进了黑洞。

稳妥的方案是给PBR加链路探测和联动。H3C上可以用NQA探测对端的可达性，把探测结果绑定到Track，再让PBR动作关联Track。大致思路如下：

先定义一个NQA探测实例，定时往ISP1的互联地址192.168.12.1发ICMP请求：

nqa entry admin monitor_isp1 type icmp-echo destination ip 192.168.12.1 frequency 5 quit nqa schedule admin monitor_isp1 start now life forever

然后创建Track来跟踪这个探测结果：

track 1 nqa entry admin monitor_isp1 reaction 1

最后在PBR的apply next-hop后面跟上Track编号，如果在设备上执行命令后看到该参数生效（各版本略有差异）：

policy-based-route pbr1 permit node 10 if-match acl 3000 apply next-hop 192.168.12.1 track 1

这样当ISP1链路异常、NQA探测失败时，Track进入Down状态，PBR节点对应用动作失效，流量会回落到普通路由表走默认路由，而不是在故障链路上死等。这个机制非常值得在真实出口场景中部署，它能把PBR从“静态指定”升级为“动态感知”。

6.3 线上割接前PBR的灰度验证习惯

最后分享一个我自己的实操习惯。PBR是直接干预数据转发路径的技术，影响面通常比路由协议变更更直接。我在模拟器里验证通过后，到真机上做割接时，不会一下子把所有流量都切过去。

先挑一个低风险的小网段，比如一个只有几台测试终端的源网段，把PBR策略只对这个网段生效，然后观察小半天。重点看display ip policy-based-route setup的命中计数是否正常增长，对应出口的接口流量是否同步变化，回程有没有异常。确认稳定后，再逐步扩大匹配范围，直到覆盖全部目标网段。

这个过程听着慢，实则是PBR上线最稳妥的路径。一条if-match写错，或者一个ACL通配符算反，就可能把整个办公网的流量引到一条断链路上，影响面完全不可控。在模拟器里多花一个小时，到现场就能少熬一个通宵。

做网络实验就是这样，配置命令只有几行，真正的价值全在“为什么要这么配”和“出了问题怎么查”上面。希望这篇H3C PBR双出口实验记录，能帮你把策略路由这个知识点彻底打通。