简介《华为路由器路由策略和策略路由》是一份系统讲解路由策略与策略路由的PDF技术文档面向网络工程师、运维人员及华为认证备考者旨在帮助读者理解路由过滤、属性修改及流量路径控制的核心机理。文档详细介绍了路由策略的三大功能——控制路由接收与发布、控制路由引入、设置特定路由属性并阐述了ACL、地址前缀列表、AS路径过滤器、团体属性过滤器等六种过滤器的匹配原理与典型应用场景同时涵盖BGP to IGP功能下私有属性匹配的注意事项。读者可据此掌握路由策略与过滤器组合实现精准路由过滤的方法减少无效路由对路由表的占用优化网络流量路径提升网络安全性与可靠性。资源为单个PDF文件大小761KB内容精炼既适合系统学习也便于快速查阅。目前已有307人学习下载是日常排错与认证复习的实用参考。1. 路由策略和策略路由调了三年网还是有人把这两个词混着用做双出口改造时最容易翻车的不是防火墙策略而是分不清“路由策略”和“策略路由”这两个词——它们读音差一个字作用却一个在控制面、一个在转发面。路由策略决定路由表里有哪些路由、路由的属性怎么写策略路由决定一个报文进来之后查不查路由表、往哪个出口走。把两者混用轻则策略配了不生效重则核心业务流量被引到错误出口。这篇文章围绕华为路由器结合AR系列的实际运维经验把两类技术的配置命令、参数含义、常见故障和验证手段串一遍适合正在做多出口改造或OSPFBGP选路的运维工程师对照复现。2. 路由策略先搞懂控制面怎么“挑食”再动route-policy2.1 路由策略的作用位置它只改变路由表不改变转发动作路由策略这个概念管的是“路由条目能不能进路由表”以及“进了路由表后带什么属性”。一台华为路由器同时跑OSPF和BGP从两个协议学到同一条前缀谁进路由表、谁的优先级高由协议优先级和路由策略一起决定。典型场景是总部和分支之间跑OSPF分支把业务网段发布上来但某些管理网段不希望被总部学到于是用filter-policy或route-policy做进向过滤。另一个常见场景是引入静态路由时打tag方便下游用tag做选路依据。路由策略不碰报文转发它只影响路由表生成的过程。这一点非常关键——很多人在接口上配了traffic policy以为能控制“路由不学”结果路由照学流量却被拦了这就是把两类策略搞反了。我在现网里见过最典型的误用想过滤一条OSPF路由却在接口下配了traffic-filter把从对端来的报文全丢了。路由确实学不到了但业务也断了。正确做法是在OSPF进程里做过滤而不是在接口上拦报文。区分“控制面”和“转发面”是理解路由策略和策略路由的第一步。2.2 filter-policy最简单的入口过滤适合“只要/不要某段路由”华为路由器上最轻量的路由策略工具是filter-policy。它支持按ACL或IP前缀列表匹配在OSPF、BGP、IS-IS等协议视图下使用分import和export两个方向。import方向控制“从邻居学来的路由是否进入本机路由表”export方向控制“本机路由是否通告给邻居”。下面是一个在OSPF视图下过滤路由的配置只拒绝10.2.0.0/24这一条其余放行。# 先定义IP前缀列表deny在前permit兜底 [Huawei] ip ip-prefix DENY_10_2 index 10 deny 10.2.0.0 24 [Huawei] ip ip-prefix DENY_10_2 index 20 permit 0.0.0.0 0 less-equal 32 # 进入OSPF进程应用进向过滤 [Huawei] ospf 1 [Huawei-ospf-1] filter-policy ip-prefix DENY_10_2 import这段配置的逻辑很清楚IP前缀列表按index从小到大匹配index 10先命中10.2.0.0/24动作是deny这条路由直接丢弃index 20的permit 0.0.0.0 0 less-equal 32是兜底保证其他所有IPv4路由正常进入路由表。如果漏掉这个permitfilter-policy默认会拒绝所有未匹配的路由导致OSPF路由全部消失。参数注意一点less-equal 32表示掩码长度小于等于32的所有路由都放行配合前面的permit 0.0.0.0 0等价于“放行所有”。这里用IP前缀列表而不是ACL是因为IP前缀列表天然支持掩码长度匹配ACL对路由前缀的掩码匹配支持较弱更容易出错。filter-policy有一个限制它只对协议学习到的路由生效无法过滤直连路由和静态路由静态路由在OSPF/BGP里通过import-route引入时用route-policy控制更合适。所以当你想“引入静态路由时做过滤”filter-policy就帮不上忙了得用route-policy。2.3 route-policyif-match与apply的完整策略框架node顺序就是判定顺序route-policy是华为路由器上最完整的策略框架核心由一个个node组成每个node里包含if-match匹配条件和apply修改动作。报文或路由进入route-policy后按node序号从小到大匹配匹配到一个node后执行该node的动作不再继续往下匹配。下面是一个经典场景把172.16.0.0/24这段静态路由引入OSPF时打上tag 100其他静态路由正常引入但不打tag。[Huawei] ip ip-prefix P_STATIC index 10 permit 172.16.0.0 24 [Huawei] route-policy TAG_STATIC permit node 10 [Huawei-route-policy] if-match ip-prefix P_STATIC [Huawei-route-policy] apply tag 100 [Huawei-route-policy] quit # 关键必须再加一个空的permit node兜底 [Huawei] route-policy TAG_STATIC permit node 20 [Huawei-route-policy] quit [Huawei] ospf 1 [Huawei-ospf-1] import-route static route-policy TAG_STATIC先看node 10if-match ip-prefix P_STATIC匹配172.16.0.0/24apply tag 100给它打上标记再看node 20没有任何if-match条件动作是permit表示“所有其他静态路由都放行”。很多人第一次配route-policy时只写了node 10结果发现OSPF里只剩这一条静态路由其他全丢了——这就是因为route-policy有隐式deny所有未被匹配的路由都会被拒绝。规则很简单要么在每个策略末尾加一个空的permit node做兜底要么确认自己是真想拒绝所有未匹配项。route-policy的if-match支持acl、ip-prefix、tag、community-filter等多种条件apply也不只限于tag还能改local-preference、cost、as-path、next-hop等。在BGP场景下route-policy是控制选路的核心工具比如用apply local-preference改变EBGP路由的本地优先级用apply as-path影响AS路径长度。但底层逻辑都是一样的先匹配再修改最后看是permit还是deny。我再强调一遍node顺序的坑route-policy匹配顺序是从小到大不是“越具体越优先”。如果你有两条规则一条permit的是明细路由一条deny的是聚合路由必须把明细放到前面否则聚合路由的deny会先命中明细路由根本轮不到匹配。这个顺序问题我见过不止一次配置一多就特别容易乱。3. 策略路由把转发决策从路由表手里抢过来3.1 PBR的生效位置在查路由表之前先问流特征策略路由就是常说的PBRPolicy-Based Routing它的位置在转发面报文从一个接口进来之后先做流分类而不是直接查路由表。如果报文匹配了PBR里定义的流特征就直接按照策略指定的下一跳或出接口转发如果不匹配才回到正常的路由表查表流程。PBR最典型的应用场景是多出口分流一条电信、一条联通办公流量走电信视频会议流量走联通。传统做法是靠明细路由或等价路由但路由表里没有那么细的条目而且运营商会下发默认路由明细路由根本选不到对应出口。PBR正好解决这个问题按源地址、目的地址、协议、端口甚至应用来分类匹配的流量强制指向特定下一跳。“在查路由表之前”这句话很多人看懂了字面意思但没理解背后的后果PBR不检查路由表里有没有这条路径它直接指定下一跳。所以如果指定的下一跳不可达流量就会丢而不是自动回落到默认路由。这跟路由策略完全相反——路由策略是修路由表PBR是绕过路由表。华为路由器上PBR有三种作用位置接口PBR作用于从该接口入方向的报文本地PBR作用于设备自己发出的报文全局PBR对所有接口生效。实际用得最多的是接口PBR下面重点讲它。3.2 接口PBR用traffic classifier和traffic behavior重定向下一跳华为路由器的接口PBR经历了两代写法。老一代是policy-based-route命令在AR G3系列上用得很普遍新一代推荐使用traffic classifier和traffic behavior组成的traffic policy框架动作更丰富也方便和QoS联动。两种写法都需要先定义ACL识别流。先看老一代写法也是网上资料最多的# 定义高级ACL匹配内网192.168.10.0/24发出的流量 [Huawei] acl number 3001 [Huawei-acl-adv-3001] rule 5 permit ip source 192.168.10.0 0.0.0.255 [Huawei-acl-adv-3001] quit # 定义策略路由节点10匹配ACL 3001 [Huawei] policy-based-route PBR_VIDEO permit node 10 [Huawei-pbr] if-match acl 3001 [Huawei-pbr] apply ip-next-hop 100.64.0.2 [Huawei-pbr] quit # 应用到接口注意方向是inbound [Huawei] interface GigabitEthernet0/0/0 [Huawei-GigabitEthernet0/0/0] ip policy-based-route PBR_VIDEO这段配置的逻辑接口GigabitEthernet0/0/0收到源地址是192.168.10.0/24的报文后策略路由先匹配ACL 3001命中后直接把下一跳改为100.64.0.2不再查路由表。apply ip-next-hop后面可以跟多个下一跳华为支持按顺序尝试第一个不可达时自动尝试第二个这能起到一定的主备效果。再看新一代traffic policy写法在较新的AR软件版本上推荐使用# 流量分类器匹配ACL 3001 [Huawei] traffic classifier C_VIDEO [Huawei-classifier-C_VIDEO] if-match acl 3001 [Huawei-classifier-C_VIDEO] quit # 流量行为重定向到下一跳 [Huawei] traffic behavior B_REDIRECT [Huawei-behavior-B_REDIRECT] redirect ip-next-hop 100.64.0.2 [Huawei-behavior-B_REDIRECT] quit # 流量策略把分类器和行为绑定 [Huawei] traffic policy P_PBR [Huawei-traffic-policy-P_PBR] classifier C_VIDEO behavior B_REDIRECT [Huawei-traffic-policy-P_PBR] quit # 应用到接口入方向 [Huawei] interface GigabitEthernet0/0/0 [Huawei-GigabitEthernet0/0/0] traffic-policy P_PBR inbound这套框架的核心是classifier、behavior、policy三层解耦classifier负责“识别什么流”behavior负责“对命中的流做什么”policy负责把两者绑起来。相比老一代policy-based-routetraffic policy里还能叠加remark dscp、remark vlan-id、count等动作做一体化策略的时候非常顺手。redirect ip-next-hop和老的apply ip-next-hop效果一致都是重定向下一跳。参数选择上有两点值得注意。第一ACL匹配的方向ACL里写的source指报文源地址destination指目的地址。做接口PBR时ACL的匹配方向是“从该接口收到的报文”所以源地址往往是内网网段。如果写反了PBR会匹配不到任何流量。第二接口下应用的方向固定是inbound华为路由器不支持在出方向应用PBR这一点和不少其他厂商的设备不同配置前要确认好。3.3 本地PBR与全局PBR按“流量从哪来”选接口PBR只能控制“从某个接口进来的流量”。路由器自己发出的报文比如网管探针、NTP同步、管理员SSH登录流量是设备本身作为源头发出的接口PBR管不着。这时要用本地PBR。[Huawei] ip local policy-based-route PBR_LOCAL必须在系统视图下执行且策略名必须已经存在。本地PBR的典型用途是让本机发出的网管流量走指定管理口或者让路由器的业务探测报文走专线而不是默认公网出口。需要注意本地PBR对除了console口和STelnet登录之外的本机流量生效配置时要避免把自己“管理断掉”。全局PBR在华为路由器上是通过traffic policy的global标识实现的适合要求所有接口入方向统一执行一套策略的场景。全局PBR要谨慎使用因为它的作用范围太大任何接口进来的流量都会先过一遍策略一旦分类条件写得过宽会干扰正常选路。我一般建议先用接口PBR解决明确需求确实有全局需求再上全局PBR并且把ACL条件写得越窄越好。4. 路由策略与策略路由的边界一张表看清“改表”还是“改路”4.1 两者生效位置与动作对比把两个概念摆在一起对比生效位置的区别一目了然。路由策略作用于路由学习、引入、通告的过程最终结果是路由表里多了或少了某条路由、某条路由的属性变了。策略路由作用于报文转发过程在查路由表之前干预最终结果是报文走了策略指定的路径。对比项路由策略策略路由PBR生效层面控制面转发面作用对象路由条目数据报文核心工具filter-policy、route-policypolicy-based-route、traffic policy常见动作permit/deny路由、打tag、改local-preference重定向下一跳、指定出接口不生效的表现路由没学到/没发布流量走了原路径或不通典型场景OSPF过滤路由、BGP选路多出口分流、强制走专线这张表看起来简单实际运维中能清晰说出“路由策略改表、策略路由改路”的人十个里未必有三个。遇到故障先问一句“问题出在路由表还是转发路径”能省下一半排查时间。4.2 四个判断标准什么时候用路由策略什么时候上PBR判断用哪个我习惯按四个问题走。第一个问题你的目的是“不让对端学到某条路由”还是“让某类流量走某条路”前者是路由策略后者是PBR。哪怕两者最终效果看起来都是“某段流量不走某条链路”本质也完全不同。第二个问题你改的东西是路由表还是报文如果你在做BGP选路希望IBGP邻居优先走某条路径改的是路由属性用route-policy配合apply local-preference。如果你在内网某台PC访问视频服务器时希望它固定走联通的线改的是报文的下一跳用PBR。第三个问题策略是否需要感知路由表的变化路由策略天然和路由表联动——路由不存在了策略自然不生效。PBR则是强制的下一跳不可达时流量直接丢。如果你的出口链路经常切换PBR需要配合NQA或BFD检测让策略在下一跳失效时自动切换否则就是给自己埋雷。第四个问题策略的粒度是“路由前缀”还是“业务流特征”按目的网段区分路由策略就够按源IP、端口、应用区分必须上PBR。比如要分流VoIP流量VoIP的RTP端口范围是固定的用ACL匹配端口再走PBR是最可靠的方案。4.3 常见误用把PBR当路由策略写进OSPF前面提到过一种误用想在OSPF里过滤路由结果在接口下用traffic policy拦报文。这里展开讲讲为什么错。OSPF的路由过滤发生在路由协议处理路由条目时接口下的traffic policy处理的是数据报文两者在协议栈里隔了好多层。你在接口下拦掉了OSPF邻居发来的Hello报文邻居关系会断路由固然学不到了但业务流量也全断了因为接口已经不收任何来自该邻居的报文。反过来还有一种误用想给视频流量强制分流却去改OSPF的接口cost希望路由表把路径切过去。这种做法的副作用是全网路由重算而且cost是全局的不只是视频流量受影响。正确的做法依然是PBR匹配视频流的ACL重定向到专线。改OSPF cost适合“永久性路径调整”不适合“按业务分流”。记住这个边界能少踩很多坑。5. 华为路由器实操避坑5个让人反复翻车的典型故障5.1 现象配完route-policyOSPF路由全没了这是我见过最多的新手事故在OSPF里import-route static时套了个route-policy结果静态路由一条都没引入OSPF域内路由也跟着出问题。原因就是route-policy的隐式deny——所有未匹配的路由默认被拒绝而配置里只写了匹配特定前缀的node没有兜底放行node。解决方法是先确认策略内容再检查匹配命中数[Huawei] display route-policy TAG_STATIC看输出里每个node的匹配次数。如果node 10的matched是0说明if-match条件根本没匹配到如果node 10有匹配但路由表里没有多半是apply动作没生效或者策略没被协议引用。然后检查OSPF引入配置确认import-route static route-policy名字拼写无误。最后在策略末尾补一个空的permit node让未匹配的路由正常放行。5.2 现象接口PBR不生效流量全走默认路由PBR配完之后用tracert一看流量还是从默认出口走的。原因排查按四个顺序来第一策略有没有应用到接口第二ACL匹配方向对不对第三策略路由里有没有被更优先的节点拦截第四下一跳在不在路由表里。直接看应用情况和命中计数[Huawei] display policy-based-route interface GigabitEthernet0/0/0 [Huawei] display traffic policy applied-recorddisplay输出里能看到策略名、接口、方向和匹配次数。如果匹配次数一直是0问题出在ACL条件上——检查source和destination是否写反扩展ACL里的通配符有没有写错。如果匹配次数在涨但流量还是走默认路由检查redirect的下一跳是否可达。华为PBR在下发时会检查下一跳的ARP和路由信息不可达的下一跳不会生效这是最常见又最隐蔽的坑。5.3 现象PBR做单向后TCP会话建立失败多出口分流只做了去程没做回程导致流量不对称。报文从联通出口出去回程却从电信出口进来中间如果有防火墙或者运营商做了严格状态检测会话直接被丢弃。现象就是网页打不开、视频卡在握手阶段。解决办法是双向策略对称如果PBR做在路由器A上把去程流量引到联通那么对端的回程流量也要有对应的策略引回联通。如果只有一台路由器做出口那就把PBR同时应用在两个接口的入方向——WAN口收到的回程流量按反向条件匹配后走对应出口。华为AR路由器有会话表但PBR本身不解决对称性问题它只负责“这个方向的报文往哪走”两个方向的策略必须由运维自己保证对称。5.4 现象登录新到的AR路由器console口一直提示输入密码较新版本的华为AR系列路由器比如V173版本上console口的默认认证方式走AAA而且出厂没有配置本地用户如果设备的出厂密码为空或未知直接回车进不去按网上老教程里的默认密码也不行。严格说这不算故障是版本策略变了但很多第一次接触新设备的工程师会卡在这一步。解决路径有两条。如果设备还没上线、没有业务配置最简单的方法是通过BootROM菜单清除console密码重启设备在出现提示时按CtrlB进入BootROM菜单选择清除console密码的选项。但注意这种方式通常会连带清空启动配置操作前务必确认设备上没有任何需要保留的配置。如果设备已经在运行业务优先走SSH远程登录登录后修改console认证方式为不认证或配置本地用户密码再把新密码记住。5.5 现象设备重启之后策略和路由全部恢复“出厂感”改完策略没保存设备一重启所有配置回到上一次save的状态。这个问题在加班割接时特别容易出现——凌晨三点改完配置验证通过忘了save第二天早上业务全断心里只剩两个字完了。华为路由器改配置后必须执行save配置才会写入下次启动的配置文件。[Huawei] save遇到这种情况不要慌先看display current-configuration里策略还在不在如果不在说明确实没保存如果配置在但路由行为不对检查是不是某些依赖项比如ACL、前缀列表没有同步保存。我给自己定的规矩是改完任何策略先display看一遍再save再display current-configuration确认一遍三步缺一步都不收工。后来我每次割接前还会顺手备份一份配置文件到本地出了事有后悔药吃。6. 一个技巧用display命令和tracert两分钟验证策略是否真生效6.1 控制面验证看路由表和route-policy命中记录配完路由策略先验证策略本身有没有被命中再看路由表结果。display route-policy能看到每个节点的匹配次数如果连续看两次数值都在涨说明有路由正在被这个策略处理。然后display ip routing-table protocol static确认静态路由有没有被引入OSPF或者display ip routing-table看指定前缀的路由是否带着预期的tag。[Huawei] display route-policy TAG_STATIC [Huawei] display ip routing-table 172.16.0.0 24 verbose第二条命令的verbose输出里能看到这条路由的tag值如果显示tag 100说明apply生效了。路由策略的验证核心就是“匹配计数在涨、路由属性对得上”这两点满足控制面就稳了。6.2 转发面验证用tracert和display ip statistics确认PBR路径PBR是转发面行为验证时不能只看配置要实际打流量看路径。最直接的办法是从内网PC tracert到目标地址观察第一跳的IP是不是PBR指定的下一跳。如果中途被运营商设备隐藏了路径可以改用display ip statistics查看接口的收发报文计数确认流量是否从预期接口进出。我带一个新人的习惯是验证PBR必须用真实业务流量或者至少用一台和业务同网段的PC去测。只用路由器本机ping验证PBR是无效的因为本机发出的流量走的是本地PBR跟接口PBR是两套逻辑。另外做完验证记得把测试用的静态路由和临时策略清掉避免给后续排障留干扰项。我一直保留的习惯是任何策略上线前先拍一张“配置前”的display current-configuration截图配完再拍一张“配置后”的比对完确认只有预期改动然后save。这个习惯帮我避免过好几次割接后无法回退的尴尬。希望帮到你。本文还有配套的精品资源点击获取