路由策略与PBR策略路由实战：多分支网络本地化与等级化部署指南

---------- 不太会画漂亮的分隔线，先说事。

干了这么多年网络，我最怕听到的一句话就是：“那个分支最近访问系统特别慢，你们看看怎么回事。”你说带宽也够，专线也通，VLAN也都在，可用户就是卡成PPT。遇到这种问题，十有八九不是因为链路质量差，而是因为你对“路由”这件事想简单了。

今天聊聊我在企业网络项目里反复用到的一套东西：路由策略、本地化资源管理和等级化路由部署。分别解决什么问题？简单讲，路由策略解决“这个包到底该走哪条路”的决策问题；本地化资源管理解决“不要让所有流量都跑到总部或出口去绕一圈”的效率问题；等级化路由部署解决“网络大了以后路由表还能不能稳得住、收敛快不快”的扩展性问题。这三件事在真实网络里往往是绑在一起做的，尤其配合最新的热词 PBR策略路由，能玩出不少花活。

这篇文章适合正被多分支组网、多链路负载、专线带宽不够、路由表混乱折腾的同行，也适合刚接触企业网的小伙伴。我会把设计思路、配置细节、踩坑实录都写出来，尽量让你看完能直接照着做。

1. 需求拆解：为什么你的分支网络越来越慢

1.1 本地化资源管理的核心痛点

先说说我常遇到的一个客户场景。某制造企业总部在华东，下面有十几个分支工厂，覆盖华南、华北、西南。早期网络很简单，所有分支接入到总部，访问ERP、MES、OA全靠总部数据中心。分支的互联网出口也统一走总部，这样便于审计和统一管控。

刚开始确实没什么问题，但随着分支下面的终端数量上来了，视频会议、监控回传、生产数据采集全往总部跑，麻烦就来了：

• 总部出口带宽从几百兆一路扩到好几G，还是经常打满，专线费用居高不下。
• 分支之间互相访问文件服务器，流量要绕到总部再回来，明明两地物理距离很近，延迟却高得离谱。
• 分支访问互联网的体验很差，所有人挤在一条跨国/跨地域的链路上，视频会议卡顿、邮件附件上传缓慢，业务部门天天投诉。

这些问题的根子其实只有一个：流量没有实现本地化。该在分支本地终结的流量跑到了总部，该走本地出口的流量挤在专线上。解决思路也不是一味加带宽，而是想办法把流量“留在该留的地方”。把常用数据在分支做缓存、把互联网出口在分支就近接入、把分支之间的互访通过区域路由直接转发，这些动作统称本地化资源管理。

1.2 等级化路由部署要解决什么问题

本地化资源管理做起来之后，网络里的路由条目会明显增多。原来所有分支只要写一条默认路由指向总部，现在可能每个分支都有多条明细路由：内部业务网段、本地缓存服务器、区域汇聚节点、多个出口链路。

如果还是扁平化地堆路由，很快会出问题：

• 路由表膨胀，设备CPU和内存压力大。
• 某个链路闪断时，所有分支都在全网范围内重新计算路由，收敛时间被拖得很长。
• 配置管理混乱，出了故障根本无法快速判断优先级。
• 网络拓扑调整时，到处都是静态路由，改一处要牵一发动全身。

所以我在做方案时一定会引入等级化的设计思路。把整个网络划分为核心层、汇聚层、接入层，路由协议分区域规划，使用路由汇总、路由过滤、管理距离等手段，让每条流量都有明确的优先级和路径。这样即使链路或设备故障，流量也能快速切换，网络的可控性和稳定性完全不一样。

2. 方案设计：流量怎么“指对路”还要“分级管”

2.1 本地出口、本地缓存与DNS分流怎么配合

先讲本地化流量管理的几个常见手段，它们需要配合使用，不是单独布一个设备就能解决的。

第一件事是分支本地互联网出口。现在很多企业会在分支放一条独立的运营商宽带，专门承载非核心业务流量，比如员工上网、外部邮件、视频会议。好处是减轻总部专线压力，坏处是安全管控难度增加。所以本地出口要配合防火墙策略、上网行为管理来部署，必要的时候把日志回传到总部的日志平台。

第二件事是本地DNS。很多慢连接其实是DNS解析慢导致的。分支本地放一台DNS缓存服务器，或者在企业内网部署智能DNS，把内部域名解析到就近的服务器，外部域名解析到本地出口的公网IP，这样访问体验会好很多。我在实际项目里经常遇到用户说“系统很慢”，结果排查了半天是每次请求都在等DNS超时。

第三件事是本地缓存与区域资源池。比如分支频繁使用的安装包、共享文档、视频培训素材，可以用一台缓存服务器做本地存储，配合路由策略把对特定域名的请求、对特定网段的访问引导到本地资源。目的就是少占用跨地域链路。

做到这一步，网络里的流量路径已经变复杂了，不再是一条“所有流量走总部”的简单模式。这时候必须靠路由策略把流量分类处理：哪些走专线、哪些走本地出口、哪些走区域汇聚，全部要有规则。

2.2 路由协议选择和等级化划分思路

等级化路由部署首先要把网络分层。我在多数中大型企业项目里采用三层架构：

• 核心层：总部核心交换机/路由器，连接数据中心、总出口、各区域汇聚。
• 汇聚层：区域汇聚设备，负责汇总区域内路由，连接分支。
• 接入层：分支出口设备，负责终端接入、本地出口和策略执行。

在三层架构基础上，路由协议的选择就有讲究了。大型网络里我倾向于动态路由协议为主、静态路由为辅。内部网关协议可以用OSPF，跨区域或者多运营商互联可以用BGP。小型网络则可以用静态路由加策略路由解决，成本更低、也更容易排障。

等级化还体现在路由汇总上。比如分支的终端网段规划成10.1.0.0/16的连续地址块，每个分支一个/24段，那么区域汇聚节点只需要向上游通告一个10.1.0.0/16，而不是十几个/24明细路由。这样核心层的路由表会非常精简，收敛速度也快。

等级化还体现在路由优先级上。比如总部到分支的主链路走专线，备链路走互联网加密隧道；在主链路正常时，动态路由通过cost值让所有流量走专线；主链路故障后，通过路由的metric和管理距离自动切换到备用链路。这里的关键是“有主有备、快速收敛”。

3. PBR策略路由实操：从一个真实配置说起

3.1 PBR是什么，什么时候必须用它

策略路由（Policy-Based Routing，简称PBR）的核心思想，就是不只看目的IP来决定下一跳，而是根据源IP、目的IP、协议、端口、报文大小等条件来灵活匹配和分流。

很多人会问，既然动态路由协议已经能选路了，为什么还要策略路由？这个问题我几乎每次做分享都会遇到。答案是：动态路由协议选路是基于“目的网段”的，它不理解业务。举个例子，到同一台服务器的流量，视频会议的数据包需要走专线保障质量，普通更新下载的数据包却希望它走本地宽带到互联网绕一圈，目的IP完全相同，动态路由根本没办法区分。只有策略路由能根据源地址、应用类型、报文特征来分流，在业务维度上实现“路随意动”。

我的经验是，下面这几类场景一定要用到PBR：

• 多运营商出口环境下，根据目的IP选择对应运营商的线路。
• 内网多个业务网段共用一条出口，但不同业务对链路质量要求不同。
• 需要把特定流量引导到安全设备、缓存设备或负载均衡设备。
• 分支访问总部和访问互联网需要走不同路径。

3.2 一个可落地的分支双出口配置案例

直接上一个我很久前在某个分支节点做过的真实配置（以华为设备为例，思科的命令差异不大，关键是思路）。这个分支有两根线：

• 一根专线到总部，用于访问内网ERP系统，网段是10.10.0.0/16，网关是10.254.0.1。
• 一根本地互联网宽带，用于访问公共网络，网关是100.64.0.1。

目标需求：内网所有员工访问总部内网时走专线；访问互联网时走本地宽带；但如果有特定网段（比如视频会议终端的网段10.1.50.0/24）访问某云会议服务（假设IP是203.0.113.0/24），必须走专线路由以保证质量。

第一步，创建ACL来匹配需要策略路由的流量：

bash复制acl number 3100
  rule 10 permit ip source 10.1.50.0 0.0.0.255 destination 203.0.113.0 0.0.0.255
  rule 20 deny ip

第二步，配置流分类、流行为和策略。流分类负责“挑流量”，流行为负责“怎么走”：

bash复制traffic classifier meeting
  if-match acl 3100

traffic behavior to_headquarter
  redirect ip-nexthop 10.254.0.1

traffic policy pbr_meeting
  classifier meeting behavior to_headquarter

第三步，把策略应用到终端网关的入方向：

bash复制interface GigabitEthernet0/0/0.10
  user-vlan 10
  traffic-policy pbr_meeting inbound

配置看起来简单，但有几个细节值得展开讲：

• ACL里的规则顺序很重要。规则10先匹配视频会议流量，规则20拒绝其余流量，不合格的流量不进入策略路由分支，按普通路由表转发。如果顺序颠倒，策略就不生效。
• 应用方向是inbound，也就是从内网进入路由器的时候决策路径。如果接到出方向，流量已经完成路由决策，PBR就晚了。
• redirect ip-nexthop后面可以跟多个下一跳做备份，这样主下一跳失效时自动切换到备下一跳。但实际使用中我一般建议配合BFD联动，否则故障切换不够快。

上面这个策略还只是针对特定业务的“点状”分流。在实际部署时，我通常会把“默认路由策略+明细策略”组合起来：先用PBR把需要特殊处理的高价值流量挑走，剩下的普通流量丢给路由表按默认路径转发。

3.3 策略路由在等级化架构中的布置位置

PBR不是哪里都能乱放的。放错了层次，轻则策略冗余，重则造成路由环路。我的建议是，尽量把PBR放在接入层或汇聚层的入方向，越靠近源端越好。

原因很简单：策略路由和状态化设备结合时，最好在流量进入网络的第一个三层设备上决策路径，这样后续设备只需要按照既有路由转发即可，路径清晰、排障容易。如果放在核心层，核心设备需要承载全网的策略判断，压力大，而且策略失效时影响面太大。

另外，等级化架构中要仔细规划“策略路由和动态路由的回程问题”。如果分支用PBR把流量引到了专线，那总部的回程路由也要对应走专线或通过动态路由协议宣告，不能出现“去程走PBR，回程走互联网”的流量路径不对称情况。流量路径不对称在生产网络里非常麻烦，尤其是在涉及NAT和防火墙时，很容易丢包。

4. 常见故障与排查技巧实录

4.1 问题一：PBR策略配置了但不生效

这是我被问得最多的问题。配置看着没问题，ACL也有匹配，为什么流量就是不按策略走？排查顺序我推荐这样来：

第一，确认策略应用方向。绝大多数人是把策略应用到了outbound方向，但流量已经完成路由查表，再应用策略就晚了，必须应用到inbound方向。

第二，确认ACL的匹配计数。华为设备里可以执行display traffic classifier statistics查看匹配统计。如果计数器不涨，说明流量根本没被分类命中，问题在ACL规则本身；如果计数器在涨但实际路径没变，问题在行为动作或下一跳可达性。

第三，确认下一跳是否可达。策略路由指定了一个不可达的下一跳，流量就会按普通路由表继续转发，看起来像“策略没生效”。建议配置后立刻ping下一跳地址确认连通性。

第四，注意递归查询。如果下一跳不是直连地址，路由器需要先查路由表找到去往该下一跳的出接口。我在静态默认路由结合PBR时踩过这个坑，明明下一跳配了，但始终不生效，后来发现去往该下一跳的路由本身没配置。

4.2 问题二：策略路由和NAT的顺序搞反了

这是双出口场景最容易出的问题。在没有NAT时，策略路由匹配源地址和目的地址都可以正常处理。但一旦涉及NAT，顺序就非常重要。

多数厂商设备的处理顺序是：路由查询/策略路由决策在前，NAT转换在后。这意味着ACL匹配的IP地址应该是NAT之前的原始地址。如果分支终端的私网地址是10.1.0.0/16，做NAT后变成了100.64.0.x，你拿转换后的地址去写ACL匹配规则，大概率一条都匹配不上。反过来，如果设备NAT处理顺序不同，也会出现类似问题。动手前先查各厂商的技术文档，确认本地设备的实际处理顺序，再决定ACL里写的是源地址转换前的还是转换后的。

解决思路是：在业务网段规模不大时，尽量把NAT策略和PBR策略都基于源网段来写。例如源地址10.1.50.0/24走专线，源地址10.1.60.0/24走本地出口，这样即使NAT顺序有差异，也能用源网段对应起来。

4.3 问题三：策略路由导致的环路与黑洞

某些场景下，PBR把流量引到一台设备，但该设备又把流量扔了回来，形成环路。最典型的是把流量引到防火墙做安全检查，防火墙检查完再从同一个接口把流量吐回路由器，路由器又匹配PBR再次送到防火墙，来回打转。

遇到这种情况，优先在防火墙上做“去PBR化”处理，比如在防火墙上把已检查的流量直接放行，或者通过VLAN隔离物理接口，让进防火墙的流量和出防火墙的流量走不同接口，避免形成环路判定。如果是旁挂模式，注意策略路由的下一跳指向防火墙的接口地址，而不是防火墙后面的网关地址。

另一个常见黑洞是“PBR指向的路径没有回程路由”。比如流量引到了备份链路上，但备份链路上游根本没有宣告该目的网段，结果数据包发出去就石沉大海。所以在配置PBR时，一定要把整条路径上的“去程+回程”一起规划好。

4.4 问题四：主备链路切换不快怎么办

本地化资源管理之后，每个分支通常都有多条链路。如果不做联动，策略路由的备用下一跳在触发切换时往往需要几十秒，对业务来说是不可接受的。

我的做法是给PBR的下一跳加上BFD会话。BFD（Bidirectional Forwarding Detection，双向转发检测）可以在毫秒级检测到链路故障，然后立即通知路由协议或策略路由进行切换。配合接口追踪（track）功能，可以实现：只要主链路断开，策略路由的下一跳自动失效，流量秒级切换到备用链路。

华为设备上的一个简化配置思路如下：

bash复制bfd
  quit

interface GigabitEthernet0/0/0
  ip address 10.254.0.2 255.255.255.0
  bfd bind peer-ip 10.254.0.1 interface GigabitEthernet0/0/0
  bfd min-tx-interval 100
  bfd min-rx-interval 100
  bfd detect-multiplier 3

traffic behavior to_headquarter
  redirect ip-nexthop 10.254.0.1 track bfd-session 1

这里把主下一跳和BFD会话绑定，BFD一旦检测到专线故障，策略路由立刻切换到备用下一跳。我在多个项目里实测，切换时间可以控制在1秒以内，视频会议基本无感。

5. 经验总结：最后再分享两个实操心得

第一个心得是，策略路由不是万能的，滥用会害死自己。我在一个项目里看到过员工把几十条PBR策略堆在核心交换机上，结果链路一抖动，策略互相冲突，全网出现间歇性丢包。我后来把架构理清，把高价值业务用PBR管控，普通流量交给动态路由协议，不到一个礼拜网络就稳定了。谨记：能用路由协议解决的，不要让策略路由扛；策略路由只处理那些路由协议管不了的业务级需求。

第二个心得是， “等级化”不是指设备堆叠等级，而是指路由决策的规范程度。网络里可以没有特别高端的设备，但不能没有清晰的区域、清晰的汇总、清晰的优先级。只要路由表是分层的、路径决策是有依据的，后期排障和扩容都会轻松很多。

这次讲的本地化资源管理、等级化路由部署和PBR策略路由，在企业网络项目里基本是三位一体的。本地化解决流量效率，等级化解决路由稳定，PBR解决业务差异化。把这套思路吃透，再去应付多分支、双出口、多链路的复杂场景，你会觉得做网络其实没那么难。