1. 策略路由到底解决的是什么问题
1.1 从一个真实场景说起
很多刚接触网络设备的朋友，第一次听到"策略路由"这四个字，脑子里冒出来的第一个念头往往是：路由不就是查表转发吗，还有什么策略不策略的？这个疑问非常正常，因为常规的路由转发确实是"目的地址决定一切"——数据包要去哪里，就查路由表里哪条最匹配，然后从对应接口丢出去。整个过程是单向的、被动的，设备本身没有任何"主观意愿"。
但现实网络里，事情远没有这么简单。我举个特别常见的例子：某公司有两条出口链路，一条是高速专线，一条是普通宽带。老板的要求是——财务部门的流量必须走专线，因为涉及资金数据，要稳；而研发部门下载大文件、看在线视频的流量走普通宽带就行，省成本。这时候你如果只用普通路由，问题就来了：普通路由表里只能有一条默认路由指向某个出口，或者靠目的地址区分，可财务和研发访问的可能是同一个外部地址，目的地址完全一样，你怎么区分？
答案就是策略路由。它让设备不再只看"目的地址"这一个维度，而是可以综合源地址、源接口、协议类型、报文大小、时间等条件，人为地指定"什么样的流量走什么样的路"。说白了，普通路由是"看目的地选路"，策略路由是"看人下菜碟"。
1.2 策略路由和普通路由的本质区别
我把两者的核心差异整理成一张表，方便你一眼看明白：
| 对比维度 | 普通路由（目的地址路由） | 策略路由（PBR） |
|---|---|---|
| 选路依据 | 仅目的IP地址 | 源IP、源接口、协议、端口、报文长度等 |
| 查找顺序 | 先查路由表，再转发 | 先匹配策略，命中后按策略转发 |
| 优先级 | 低于策略路由 | 高于普通路由 |
| 典型用途 | 常规互联互通 | 分流、负载、特定业务保障 |
| 配置位置 | 路由表 | 策略节点（Policy-Based Route） |
这里有个特别关键的顺序问题，很多人栽跟头就栽在这：策略路由的优先级高于普通路由。也就是说，一个数据包进来，设备会先看有没有匹配的策略路由，如果命中了，就按策略走，根本不去查普通路由表；只有没命中任何策略，才回退到普通路由转发。这个"先策略后路由"的顺序，是理解整个机制的地基。
1.3 为什么要在eNSP里练策略路由
eNSP是华为官方出的网络模拟器，全称Enterprise Network Simulation Platform。它最大的好处是能在一台普通电脑上虚拟出路由器、交换机、防火墙等一整套设备，随便你怎么折腾，配错了大不了重启，不用担心把真设备搞挂。对于策略路由这种"配置逻辑绕、验证步骤多"的技术点来说，模拟器简直是练手神器。
我个人的建议是：策略路由这东西，光看文档是学不会的，必须自己动手配一遍、抓一次包、看一次路由表，才能真正理解它"先于路由表生效"这个特性。下面我就带着你从零搭一个能跑通策略路由的实验环境，把每个环节掰开揉碎讲清楚。
2. 实验环境搭建与基础配置
2.1 拓扑设计与设备选型
先明确我们要做什么。我设计一个最经典也最能说明问题的拓扑：三台路由器，R1作为核心出口设备，R2和R3分别模拟两条不同的出口链路，R1后面挂一个模拟内网用户的PC。
具体连接关系是这样的：
- PC1（模拟财务部门，网段192.168.10.0/24）连接到R1的GE0/0/0接口
- PC2（模拟研发部门，网段192.168.20.0/24）连接到R1的GE0/0/1接口
- R1的GE0/0/2接口连接R2（模拟高速专线出口）
- R1的GE0/0/3接口连接R3（模拟普通宽带出口）
- R2和R3各自再连一个模拟外网的设备或者直接用一个Loopback模拟外部目标
选这个拓扑的理由很直接：它把"两个源网段、两个出口"这个策略路由最核心的分流场景完整呈现出来了。财务走R2，研发走R3，目标都是同一个外部地址，靠普通路由根本没法区分，只能靠策略路由。
在eNSP里搭建的时候，路由器我一般选AR2220，这款型号功能全、支持的特性多，策略路由相关的命令都能跑。PC用eNSP自带的PC就行，配置简单。
2.2 IP地址规划与接口配置
地址规划这块我建议一开始就做清楚，不然后面排查问题会非常痛苦。我的规划如下：
| 设备 | 接口 | IP地址 | 说明 |
|---|---|---|---|
| R1 | GE0/0/0 | 192.168.10.1/24 | 财务网关 |
| R1 | GE0/0/1 | 192.168.20.1/24 | 研发网关 |
| R1 | GE0/0/2 | 10.0.12.1/24 | 连R2 |
| R1 | GE0/0/3 | 10.0.13.1/24 | 连R3 |
| R2 | GE0/0/0 | 10.0.12.2/24 | 连R1 |
| R2 | Loopback0 | 8.8.8.8/32 | 模拟外部目标 |
| R3 | GE0/0/0 | 10.0.13.2/24 | 连R1 |
| R3 | Loopback0 | 8.8.8.8/32 | 模拟外部目标 |
注意这里我故意让R2和R3的Loopback地址都是8.8.8.8，就是为了制造"目的地址相同、必须靠源地址区分"的场景。如果两个出口的目标地址不一样，那普通路由就能搞定，就体现不出策略路由的价值了。
R1的基础配置命令如下：
system-view sysname R1 interface GigabitEthernet0/0/0 ip address 192.168.10.1 255.255.255.0 interface GigabitEthernet0/0/1 ip address 192.168.20.1 255.255.255.0 interface GigabitEthernet0/0/2 ip address 10.0.12.1 255.255.255.0 interface GigabitEthernet0/0/3 ip address 10.0.13.1 255.255.255.0R2和R3的配置类似，配好接口地址和Loopback即可。这里有个小细节：Loopback接口默认是up的，配完地址就能用，非常适合用来模拟稳定的外部目标。
2.3 先跑通普通路由，建立对照基线
在配策略路由之前，我强烈建议你先把普通路由配通，让PC能ping通8.8.8.8。这一步的意义在于建立一个"对照组"——你能看到没有策略路由时，流量是怎么走的，然后再加策略，对比效果。
在R1上配两条静态路由：
ip route-static 8.8.8.8 32 10.0.12.2 ip route-static 8.8.8.8 32 10.0.13.2这里你会发现一个问题：两条路由的目的地址和掩码完全一样，设备只会选其中一条（默认选先配的或者根据优先级），另一条等于摆设。这就是普通路由的局限——它没法根据源地址做区分。你可以在PC1上ping 8.8.8.8，然后在R1上用display ip routing-table 8.8.8.8看看到底走了哪条。
提示：如果两条静态路由完全等价，设备可能会做负载分担，但这是"随机"的，不是"按部门"的，财务的流量可能跑到普通宽带上，这恰恰是我们要避免的。
3. 策略路由的核心配置与实现
3.1 策略路由的三大组成要素
华为设备上的策略路由，核心是三个东西配合：ACL（访问控制列表）、流分类（traffic classifier）、流行为（traffic behavior），最后用**流策略（traffic policy）**把它们串起来，再应用到接口上。这套组合拳叫MQC（Modular QoS Command-Line Interface），是华为设备做流分类和策略处理的通用框架。
我用大白话解释一下这三个角色的分工：
- ACL：负责"认人"，也就是定义什么样的流量需要被特殊处理。比如"源地址是192.168.10.0/24的流量"。
- 流分类：负责"贴标签"，把ACL匹配到的流量归为一类，起个名字方便引用。
- 流行为：负责"下指令"，告诉设备这类流量该怎么处理，比如"重定向到某个下一跳"。
- 流策略：负责"拉郎配"，把流分类和流行为绑在一起，形成一条完整规则。
这个框架的好处是灵活，你可以定义多个分类、多个行为，自由组合。理解了这套逻辑，后面配什么策略都是换汤不换药。
3.2 用ACL定义需要分流的流量
第一步，我们先定义财务部门的流量。在R1上创建一个高级ACL（编号3000以上是高级ACL，可以匹配源地址、目的地址、协议等）：
acl number 3000 rule 5 permit ip source 192.168.10.0 0.0.0.255 destination 8.8.8.8 0这条规则的意思是：允许源地址在192.168.10.0/24网段、目的地址是8.8.8.8的IP流量。反掩码0.0.0.255对应/24，0对应/32，这个换算关系要记牢。
同理，研发部门的流量也定义一个ACL：
acl number 3001 rule 5 permit ip source 192.168.20.0 0.0.0.255 destination 8.8.8.8 0这里有个经验之谈：ACL的rule编号我习惯从5开始，每次加10，这样以后要在中间插规则的时候有空间，不用重新编号。这个习惯在规则多了以后能省不少事。
3.3 配置流分类和流行为
接下来定义流分类，把ACL匹配的流量归类：
traffic classifier caiwu operator or if-match acl 3000 traffic classifier yanfa operator or if-match acl 3001operator or表示分类内多条匹配规则之间是"或"的关系，只要命中一条就算匹配。这里每个分类只有一条规则，用or还是and都一样，但养成写清楚的习惯没坏处。
然后定义流行为，指定流量该怎么走。策略路由的流行为用redirect关键字：
traffic behavior to_R2 redirect ip-nexthop 10.0.12.2 traffic behavior to_R3 redirect ip-nexthop 10.0.13.2redirect ip-nexthop的意思是：把匹配的流量强制重定向到指定的下一跳地址。注意这里是"下一跳"，不是"出接口"，因为指定下一跳更精确，设备会自动递归查找到达这个下一跳的出接口。
注意：redirect后面还可以跟
interface参数指定出接口，但在以太网这种多路访问环境里，指定下一跳比指定接口更可靠，因为接口可能连了多个邻居，设备不知道该把包发给谁。
3.4 绑定流策略并应用到接口
最后一步，把分类和行为绑成流策略，应用到R1的入接口上：
traffic policy pbr_policy classifier caiwu behavior to_R2 classifier yanfa behavior to_R3 interface GigabitEthernet0/0/0 traffic-policy pbr_policy inbound interface GigabitEthernet0/0/1 traffic-policy pbr_policy inbound这里有个极其关键的细节：策略路由必须应用在流量的入接口上。为什么？因为策略路由是在数据包进入设备、还没查路由表之前就要做决策的。如果你应用在出接口，包都已经查完路由准备发出去了，再改就来不及了。这个"入接口"的原则，是新手最容易搞错的地方，我见过太多人配了半天没效果，最后发现是应用方向搞反了。
另外，同一个流策略可以应用到多个接口，我这里把财务和研发两个接口都应用了同一个策略，因为策略里已经用ACL区分了不同源网段，所以一个策略就够了。
3.5 验证策略路由是否生效
配置完成后，验证是必不可少的环节。我一般分三步走：
第一步，在PC1（财务）上ping 8.8.8.8，然后在R1上抓包或者看接口计数，确认流量走了GE0/0/2（R2方向）。
第二步，在PC2（研发）上ping 8.8.8.8，确认流量走了GE0/0/3（R3方向）。
第三步，用display traffic policy statistics interface GigabitEthernet0/0/0 inbound查看策略命中计数，这个命令能直接告诉你有多少包命中了策略，非常直观。
如果PC1和PC2的流量分别走了不同的出口，说明策略路由生效了。这时候你再去display ip routing-table 8.8.8.8看，会发现路由表里可能只有一条路由，但实际转发却分了两条路——这正是策略路由"绕过路由表"的体现。
4. 常见问题排查与实战避坑
4.1 策略配了但完全不生效
这是最高频的问题，我把它拆成几个排查方向：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 策略完全不命中 | 应用在了出接口 | 检查traffic-policy是否配在inbound |
| 策略完全不命中 | ACL没匹配上 | 用display acl确认规则和计数 |
| 部分流量不生效 | ACL反掩码写错 | 核对通配符掩码换算 |
| 重定向后不通 | 下一跳不可达 | ping下一跳地址确认连通性 |
| 重定向后不通 | 缺少回程路由 | 检查对端是否有回包路由 |
我重点说说"应用在出接口"这个坑。很多人直觉上觉得"我要控制流量从哪个口出去，那当然配在出接口"，这个直觉是错的。策略路由是入方向决策，必须配在inbound。你可以这样记：包一进门就要决定它去哪，等它要出门了再决定就晚了。
4.2 ACL匹配不上的隐蔽原因
ACL匹配不上，除了掩码写错，还有一个特别隐蔽的原因：ACL规则的方向性。ACL本身不区分方向，但你在流分类里引用它的时候，匹配的是报文的源和目的。如果你把源和目的写反了，比如把"源192.168.10.0"写成了"目的192.168.10.0"，那流量从内网出去的时候，源是192.168.10.x没错，但你的规则要求目的是192.168.10.x，自然匹配不上。
排查这个问题的技巧是：先在ACL规则后面加个计数，或者用display acl 3000看每条规则的匹配计数。如果计数一直是0，那基本就是匹配条件写错了。
4.3 重定向后业务不通的排查思路
策略路由配对了、命中了，但业务还是不通，这种情况通常是"去程对了、回程断了"。因为策略路由只影响本设备的转发，对端设备并不知道你这边做了特殊处理，它回包的时候还是按自己的路由表走。
举个例子：财务流量被重定向到R2，R2收到包后要回给192.168.10.0/24网段。如果R2上没有到192.168.10.0/24的路由，回包就丢了。解决办法是在R2上配一条回程路由：
ip route-static 192.168.10.0 255.255.255.0 10.0.12.1同理R3上也要配到192.168.20.0/24的回程路由。这个"双向都要通"的意识，是排查网络问题的基础功。
4.4 策略路由与NAT、防火墙的配合
实际生产环境里，策略路由往往不是单独用的，它经常和NAT、防火墙策略一起出现。这里有个顺序问题需要特别注意：在华为设备上，策略路由的优先级高于NAT。也就是说，流量先被策略路由重定向，然后再做NAT转换。如果你发现NAT没生效，可能是策略路由把流量导到了一个没有配NAT的出口。
这个坑我在实际项目里踩过：本来想让某段流量走专线并做NAT，结果策略路由把它导到了另一个出口，那个出口没配NAT，导致内网地址直接暴露出去，业务直接不通。后来在策略路由的流行为里加了NAT相关配置才解决。所以配策略路由的时候，一定要想清楚这条路径上的NAT和防火墙策略是否配套。
5. 策略路由的进阶玩法与扩展思路
5.1 基于报文长度的分流
除了按源地址分流，策略路由还能按报文长度分流，这个玩法很有意思。比如你可以让大包走带宽大的链路，小包走延迟低的链路。ACL里可以用fragment-type或者直接在流分类里匹配报文长度范围。
这种玩法适合那种"既要带宽又要低延迟"的混合业务场景。不过要注意，按长度分流会增加设备处理负担，因为每个包都要判断长度，在高流量环境下要谨慎使用。
5.2 策略路由与链路探测联动
单纯的策略路由有个致命弱点：它不管链路通不通，只要配了就硬往那个方向导。如果专线断了，财务流量还是往专线导，结果就是业务中断。解决办法是让策略路由和链路探测联动，比如用NQA（网络质量分析）探测链路状态，链路断了就自动切换策略。
这个联动配置稍微复杂一点，核心思路是用track关联NQA探测结果，然后在流行为里引用track。链路正常时走专线，链路故障时自动回退到备用路径。这套机制在生产环境里非常实用，是策略路由从"能用"到"好用"的关键一步。
5.3 策略路由的优先级与匹配顺序
当一个接口上应用了多个流策略，或者一个流策略里有多个分类时，匹配顺序就变得很重要。华为设备的规则是：按流策略里分类的配置顺序从上往下匹配，命中即停止。所以你要把最精确、最特殊的规则放在前面，把通用的、兜底的规则放在后面。
这个顺序逻辑和ACL的规则顺序是一样的。我见过有人把"所有流量走A"的规则放在第一条，结果后面所有精细规则都失效了，因为第一条就把所有流量都匹配走了。记住：策略路由是"先到先得"，不是"最精确优先"。
5.4 从策略路由到策略路由的排错工具链
最后分享一套我常用的排错工具链，按顺序用下来基本能定位90%的问题：
display acl all—— 看ACL规则和匹配计数，确认流量有没有被识别display traffic classifier user-defined—— 看流分类配置display traffic behavior user-defined—— 看流行为配置display traffic policy user-defined—— 看流策略绑定关系display traffic policy statistics interface xxx inbound—— 看接口上的策略命中统计display ip routing-table—— 确认普通路由表状态- 在关键接口抓包 —— 最终确认流量实际走向
这套流程从"规则定义"到"实际转发"逐层验证，哪一层断了就查哪一层，比盲目改配置高效得多。
我个人在实际操作中的体会是，策略路由这东西，配置本身不难，难的是理解它"先于路由表生效"这个本质，以及"入接口应用"这个方向。把这两点吃透，剩下的就是熟练度问题。另外，每次配完策略路由，一定要用统计命令确认命中情况，不要凭感觉觉得"应该生效了"，网络这行，眼见为实。
