做网络的人早晚会撞上这样一个需求内网有两条出口链路领导指定“财务部门的流量必须走专线其他上网流量走普通宽带”然后你觉得这很简单在出口设备上多写几条静态路由不就完事了吗真正敲完命令你会发现路由表只认目的地址它根本不在乎这个包是从哪个网段来的。这种时候能派上用场的正是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。很多人在这一步就乱掉了其实分工很明确。对比项路由策略 Route-Policy策略路由 PBR作用对象路由信息路由属性、路由条目转发的数据报文生效位置路由协议收发、路由引入/过滤时报文入接口、查路由表之前对路由表的影响会通过过滤或改属性影响路由表生成不改变路由表只决定报文往哪送典型命令route-policy、apply cost、apply tagpolicy-based-route、if-match、apply next-hop一句话记忆路由策略是决定“路由表长什么样”策略路由是决定“数据包走哪条路”。前者管控制平面后者管转发平面。考试和现场排障都爱考这个区别务必记牢。2. 实验环境准备与拓扑设计双出口分流场景怎么搭2.1 模拟器选择与启动时的坑这个实验用HCLH3C 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口连接R2R1的G0/0/2口连接R3。R2和R3各有一个Loopback地址当作外网服务器来用。设备接口IP地址用途R1G0/0/0192.168.10.254/24主192.168.20.254/24从内网网关R1G0/0/1192.168.12.2/30接ISP1R1G0/0/2192.168.13.2/30接ISP2R2G0/0/1192.168.12.1/30与R1互联R2Loopback02.2.2.2/32模拟外网目标R3G0/0/1192.168.13.1/30与R1互联R3Loopback03.3.3.3/32模拟外网目标PC1网卡192.168.10.1/24网关192.168.10.254业务网段1PC2网卡192.168.20.1/24网关192.168.20.254业务网段2这个拓扑里最关键的设计点是R1的默认路由指向ISP2R3而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默认走ISP2R2和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.254PC2能ping通网关192.168.20.254R1到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.255ACL命名编号可以和网段呼应3000绑给192.168.10.0/243001绑给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侧的R2node 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时有PBR时判定PC1访问2.2.2.2不通R1送R3R3不知目标通命中PBR node 10走R2PBR已接管PC1流量PC2访问3.3.3.3通默认路由走R3通命中PBR node 20走R3路径不变但受PBR控制R1上display ip policy-based-route setup无统计node 10/20命中数增长转发面确认R1 G0/0/1接口计数PC1测试时无增长PC1测试时有输出接口级别确认这套组合拳打下来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双出口实验记录能帮你把策略路由这个知识点彻底打通。 
长河君 · 2026/10/20 21:30:49 · 阅读 1.2k 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。很多人在这一步就乱掉了其实分工很明确。对比项路由策略 Route-Policy策略路由 PBR作用对象路由信息路由属性、路由条目转发的数据报文生效位置路由协议收发、路由引入/过滤时报文入接口、查路由表之前对路由表的影响会通过过滤或改属性影响路由表生成不改变路由表只决定报文往哪送典型命令route-policy、apply cost、apply tagpolicy-based-route、if-match、apply next-hop一句话记忆路由策略是决定“路由表长什么样”策略路由是决定“数据包走哪条路”。前者管控制平面后者管转发平面。考试和现场排障都爱考这个区别务必记牢。2. 实验环境准备与拓扑设计双出口分流场景怎么搭2.1 模拟器选择与启动时的坑这个实验用HCLH3C 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口连接R2R1的G0/0/2口连接R3。R2和R3各有一个Loopback地址当作外网服务器来用。设备接口IP地址用途R1G0/0/0192.168.10.254/24主192.168.20.254/24从内网网关R1G0/0/1192.168.12.2/30接ISP1R1G0/0/2192.168.13.2/30接ISP2R2G0/0/1192.168.12.1/30与R1互联R2Loopback02.2.2.2/32模拟外网目标R3G0/0/1192.168.13.1/30与R1互联R3Loopback03.3.3.3/32模拟外网目标PC1网卡192.168.10.1/24网关192.168.10.254业务网段1PC2网卡192.168.20.1/24网关192.168.20.254业务网段2这个拓扑里最关键的设计点是R1的默认路由指向ISP2R3而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默认走ISP2R2和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.254PC2能ping通网关192.168.20.254R1到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.255ACL命名编号可以和网段呼应3000绑给192.168.10.0/243001绑给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侧的R2node 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时有PBR时判定PC1访问2.2.2.2不通R1送R3R3不知目标通命中PBR node 10走R2PBR已接管PC1流量PC2访问3.3.3.3通默认路由走R3通命中PBR node 20走R3路径不变但受PBR控制R1上display ip policy-based-route setup无统计node 10/20命中数增长转发面确认R1 G0/0/1接口计数PC1测试时无增长PC1测试时有输出接口级别确认这套组合拳打下来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双出口实验记录能帮你把策略路由这个知识点彻底打通。