路由策略这个技术单独看每个命令都不难懂ACL、懂路由协议基本就能搭出来。但如果只停留在敲命令层面实验做完大概率还是一头雾水——因为这玩意儿真正的难度不在于配置语法而在于想清楚你到底想让哪条路由消失让哪条路由改头换面让哪类流量从哪条链路出去。这三个问题一旦纠缠在一起Route-Policy和PBR策略路由就是绕不开的那对组合。我这次整理的这个实验练习就是为了把这两条主线彻底掰开揉碎。整套实验基于华为eNSP模拟器用一台总部路由器加两台模拟ISP的出口设备把路由策略里最常碰到的场景都过一遍用Route-Policy控制路由引入和属性修改用Filter-Policy做接收方向过滤再用PBR策略路由按源地址强制指定出口链路。做完这一轮你对控制平面和数据平面到底是怎么被策略影响的会有非常直观的体感。适合刚学完基础路由、准备啃HCIP或CCNP的网工也适合那些在现网里用过但一直没搞懂为什么要这样配的兄弟。1. 动手前先理清路由策略和PBR策略路由各管哪一段1.1 路由策略本质上是给路由加闸门先说个容易被忽视的前提。路由协议本身只会做一件事把路由从一端搬到另一端然后根据开销、优先级这类参数选出一条最优路径放路由表。但现实网络不可能这么天真——你不可能让分支的每个网段都有权限访问总部全部资源也不可能让两条出口链路不加区分地平均分摊流量。这时候就需要一个中间人在路由被接收、发布、引入的某个节点上插一手要么过滤掉某些路由要么修改路由的属性要么改变别人的选路结果。这个东西就是路由策略。它在控制平面上干活操作对象是路由本身。你可以把它想象成快递分拣线上的操作员包裹路由到你这个环节你可以选择直接放行、贴上新的标签、或者直接扔下来不让它继续走。执行这个操作的工具就是Route-Policy、Filter-Policy、ACL、前缀列表这一套它们组合起来就构成了路由策略的完整工具箱。1.2 别看都是策略五个工具各管一摊新手最容易犯的错是把ACL、前缀列表、Route-Policy、Filter-Policy、PBR这五个概念混在一起用。实际上它们之间是素材和策略的关系。ACL和前缀列表是素材用来做匹配条件Route-Policy和Filter-Policy是执行体用来决定匹配到之后怎么办PBR策略路由则是另一个维度它不碰路由表本身而是在转发数据包时插一脚强制指定下一跳或出接口。我列个表你就明白了工具匹配对象作用位置典型场景ACL源/目的IP、协议、端口等各种策略的匹配条件抓取特定报文流前缀列表路由前缀和掩码长度路由策略、路由过滤精确匹配某条路由网段Filter-Policy路由协议的路由路由接收/发布方向只过滤路由不改属性Route-Policy路由属性、前缀、ACL引入、发布、接收方向过滤修改属性PBR策略路由数据报文的五元组接口入/出方向按源地址强制指定出口特别注意Filter-Policy和Route-Policy的区别。Filter-Policy是纯过滤器只有放行和拒绝不能改属性Route-Policy除了过滤还能用apply子句改cost、tag、preference、community这些属性。实战中能用Filter-Policy解决的问题就尽量别上Route-Policy——后者的node匹配逻辑一旦写复杂了后期维护真的脑壳疼。1.3 这次实验为什么把Route-Policy和PBR放一起做因为这个组合最能暴露你对网络的理解层次。我的真实体会是很多人配置Route-Policy时会犯迷糊因为Route-Policy用node组织规则匹配顺序、permit/deny语义、以及默认deny的坑非常多而PBR策略路由又是另一个逻辑它是直接绕过路由表做转发决策。两个东西如果分开学很容易产生我全会了的错觉放一起做实验才能发现自己的知识断层到底在哪。还有一个关键点Route-Policy和PBR虽然都用if-match但它们服务的层面完全不同。Route-Policy改的是路由表里有什么PBR管的是数据包实际怎么走。路由表里有路由不代表流量一定走那条路流量走了某条路也不代表路由表里就一定是那条路。我当年做这个实验的时候把这两个场景放在同一个拓扑里用同一批ACL和前缀列表去控制做完才发现理解完全不一样了。2. 实验环境与场景设计一台出口路由器加两个ISP2.1 拓扑规划模拟双出口选路和路由过滤的真实场景整个实验拓扑我尽量压到最干净但也足够覆盖典型场景四台路由器。R1模拟总部的核心网关带两个内网网段分别是视频会议网段和办公网段R2是总部出口路由器连接两个模拟ISPR3和R4分别模拟ISP-A和ISP-B各自用Loopback接口模拟公网地址。R1和R2之间跑OSPFR2与R3、R4之间用静态路由模拟运营商接入。这个拓扑最贴近真实企业双出口场景内网有多个业务网段出口有多条链路需要做选路控制和路由隔离。我在eNSP里用的都是AR2220路由器完全够跑不用起太多设备资源占用也低。2.2 IP编址与底层协议配置具体的接口编址如下设备接口IP地址说明R1G0/0/010.0.12.1/24连接R2R1Loopback0192.168.10.1/24模拟视频会议网段R1Loopback1192.168.20.1/24模拟办公网段R2G0/0/010.0.12.2/24连接R1R2G0/0/110.0.23.2/24连接ISP-A(R3)R2G0/0/210.0.24.2/24连接ISP-B(R4)R3G0/0/010.0.23.3/24连接R2R3Loopback08.8.8.8/32模拟公网地址R4G0/0/010.0.24.4/24连接R2R4Loopback08.8.8.8/32模拟公网地址R3和R4都宣告8.8.8.8/32是为了模拟同一个公网地址双ISP可达的真实场景。同时我还在R3和R4上各加了一条9.9.9.9/32的Loopback用来做路由过滤实验——这样R2上面就同时存在多条外部路由方便观察Route-Policy到底过滤了谁、放行了谁。底层配置很简单。R1和R2之间跑OSPFR1把自己的两个内网网段宣告进去# R1 ospf 1 router-id 1.1.1.1 area 0.0.0.0 network 10.0.12.0 0.0.0.255 network 192.168.10.0 0.0.0.255 network 192.168.20.0 0.0.0.255R2只宣告互联网段并且把去往两个公网地址的静态路由写进去通过OSPF重发布给R1。R3和R4上各配一条默认路由指回R2保证回程路径能通# R3 ip route-static 0.0.0.0 0 10.0.23.2 # R4 ip route-static 0.0.0.0 0 10.0.24.22.3 把实验需求拆成三条再动手很多人在模拟器里做实验都是拿到拓扑就开始敲命令敲到后面完全不知道自己想验证什么。我的做法是先写需求清单确保每一个配置动作都有对应的验证目标。这次实验我定了三条主线需求一R2重发布外部路由进OSPF时用Route-Policy只允许8.8.8.8/32进入内网过滤掉9.9.9.9/32同时把8.8.8.8/32的开销类型改成Type-1、Cost改成50方便在内网路由器上核对效果。需求二在R1的OSPF接收方向用Filter-Policy做二次过滤即使9.9.9.9/32被通告过来也不允许进R1的路由表。需求三在R2的入接口上配置PBR策略路由视频会议网段192.168.10.0/24强制走ISP-A链路办公网段192.168.20.0/24强制走ISP-B链路。三条需求覆盖了路由引入方向的策略、路由接收方向的过滤、数据转发方向的策略路由基本把路由策略实验的核心玩法都包含了。下面我一个个说配置和验证。3. 实验一用Route-Policy在路由引入方向做控制和属性修改3.1 写好前缀列表让匹配条件足够精确Route-Policy的匹配条件我从来不用ACL去匹配路由网段因为ACL匹配的是报文的源和目的语义上就不是为路由设计的写起来还要算反掩码容易犯迷糊。前缀列表ip ip-prefix是专门匹配路由前缀和掩码长度的工具语义清晰得多。在R2上我先定义两条前缀列表把需要放行的8.8.8.8/32精确抓出来# R2 ip ip-prefix isp-permit index 10 permit 8.8.8.8 32注意这里的32表示精确匹配32位掩码。如果写成less-equal 32 greater-equal 32也是一样的效果但简洁写法就够用了。如果我不写掩码长度前缀列表默认匹配所有掩码这会导致匹配范围失控所以精确掩码长度是必须的。3.2 Route-Policy的node逻辑匹配到就停没匹配就默认拒绝接下来配置Route-Policy。这个部分最能体现Route-Policy的核心逻辑多个node按序号从小到大执行匹配到某个node后立即停止不再往下看如果所有node都没匹配最终默认deny。我的策略是两条node# R2 route-policy REDIST-ISP permit node 10 if-match ip-prefix isp-permit apply cost-type type-1 apply cost 50 route-policy REDIST-ISP deny node 20node 10放行8.8.8.8/32同时把开销类型改成Type-1、Cost改成50。node 20是显式deny把剩下所有没匹配到的东西全部拒绝掉——在路由引入场景里deny就是不引入这条路由。即使不写这个deny nodeRoute-Policy本身也有默认拒绝兜底但显式写出来更容易让读配置的人理解你的意图。还有一点必须记住在同一Route-Policy里每个node的名字相同node编号不同。多个if-match条件在同一个node内是与的关系全部满足才执行apply。如果你想表达条件A或条件B的或关系必须拆成两个node。配置完成之后把Route-Policy挂到OSPF的静态重发布方向# R2 ospf 1 import-route static route-policy REDIST-ISP这条命令的意思是R2把静态路由重发布进OSPF时每一条静态路由都要过一遍REDIST-ISP这个策略。8.8.8.8/32命中node 10被引入且属性被修改9.9.9.9/32不匹配node 10最终被deny不会进入OSPF。3.3 验证路由表变化才是唯一标准在R1上查看路由表确认预期效果# R1 display ip routing-table Destination/Mask Proto Pre Cost NextHop Interface 8.8.8.8/32 O_ASE 150 50 10.0.12.2 GigabitEthernet0/0/0 9.9.9.9/32 O_ASE 150 50 10.0.12.2 GigabitEthernet0/0/0先说明一下如果我没记错第一次做实验时的情况因为R3和R4都通告了9.9.9.9/32R2上也有两条等价静态路由重发布之后R1会同时看到9.9.9.9/32。这个输出说明策略还没生效或者是配置顺序有问题。正确的生效结果应该是这样# R1 display ip routing-table Destination/Mask Proto Pre Cost NextHop Interface 8.8.8.8/32 O_ASE 150 50 10.0.12.2 GigabitEthernet0/0/09.9.9.9/32消失8.8.8.8/32的前缀还保留着O_ASEOSPF外部路由标记Cost显示为50说明Type-1的Cost计算方式生效了。再用display ospf lsdb看LSA你会发现9.9.9.9/32这条AS External LSA在R2上根本没有生成因为重发布的时候就把它过滤掉了。这就是控制平面过滤的特点源头就不让进协议后面自然看不到。3.4 扩展Filter-Policy在接收方向做二次过滤如果别人已经在源头发了9.9.9.9/32但你这边接收方向才想起来过滤这时候就要用Filter-Policy。我在R1上加一个接收方向的过滤# R1 ip ip-prefix isp-accept index 10 permit 8.8.8.8 32 ospf 1 filter-policy ip-prefix isp-accept import配置完之后即使R2通告了9.9.9.9/32R1的路由表里也不会有这条路由但R1的OSPF LSDB里仍然保存着9.9.9.9/32的LSA——因为Filter-Policy只影响路由表生成不影响邻居关系和LSDB。这个区别很值得玩味Route-Policy在R2的重发布方向把路由拦在源头LSDB里根本没有Filter-Policy在R1的接收方向把路由拦在落地前LSDB还在路由表没有。两者不是一回事排查问题的时候一定要先搞清自己操作的是哪个方向。还有一个坑必须提醒华为设备上OSPF的Filter-Policy import对区域内路由Area内部通过LSA-1/LSA-2学会的路由基本不生效它主要作用于外部路由和区域间路由。所以我这个实验特意用了外部路由做演示不要在OSPF区域内路由上测试这个命令然后怀疑人生。4. 实验二PBR策略路由强制指定出口链路4.1 PBR和路由策略的层级差异做完路由策略实验接着做PBR策略路由你会明显感觉到思路的转换。Route-Policy处理的是路由PBR处理的是报文。可以这样理解路由策略相当于修改地图改完之后所有流量按照新地图走PBR则是给某个方向的流量雇了一个专属向导不管地图怎么画向导直接把车带到你指定的路。PBR策略路由的运行顺序是先于路由表查表的。报文进入设备、查FIB之前先看有没有策略命中命中就按策略指定的下一跳或出接口转发没命中的话才走正常路由表。4.2 先把ACL分类规则写好在R2上我要把两个内网网段区分开所以先用高级ACL抓不同源地址的报文。这里高级ACL匹配的是数据报文和路由前缀没关系所以ACL是正确的工具。# R2 acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 acl number 3002 rule 5 permit ip source 192.168.20.0 0.0.0.255写ACL的时候注意反掩码0.0.0.255表示匹配192.168.10.0/24这个网段的所有地址。很多人在这一步把反掩码写成0.0.255.255那匹配的就不再是/24网段了。写完之后用display acl all确认一下规则再往下走。4.3 配置传统PBR一个策略里放两条node接下来在R2上配置策略路由。华为AR路由器支持两种方式传统policy-based-route适合纯路径调度配置直观MQC的traffic policy方式适合和QoS、统计联动。我这个实验用传统方式更容易看清策略路由的原理# R2 ip policy-based-route PBR-OUT permit node 5 if-match acl 3001 apply ip next-hop 10.0.23.3 ip policy-based-route PBR-OUT permit node 10 if-match acl 3002 apply ip next-hop 10.0.24.4node 5匹配视频会议网段下一跳强制指向R3ISP-Anode 10匹配办公网段下一跳强制指向R4ISP-B。然后把这个策略应用到R2的内网入接口# R2 interface GigabitEthernet0/0/0 ip policy-based-route PBR-OUT这里有个关键认知策略路由应用在入接口而不是出接口。它拦截的是从内网方向进来的流量在R2转发决策前进行干预。如果你把策略放在出接口上方向就会弄错。同时要记住设备自己产生的流量不会经过入接口的PBR。也就是说你在R2上直接ping 8.8.8.8不会匹配这个策略它走的是R2自己的路由表。这个特点我每次实验都得提醒自己防止验证的时候自己被自己坑了。4.4 验证PBR到底生效没有tracert是最直观的手段PBR生效之后R2路由表不会发生任何变化——8.8.8.8/32的主路由仍然是preference 60的那个指向R3的静态路由。但实际转发路径已经被策略接管了。在R1上分别指定源地址做tracert这是最直观的验证方式# R1 tracert -a 192.168.10.1 8.8.8.8如果PBR生效路径的下一跳会清晰展现出报文走了哪条链路1 10.0.12.2 20 ms 10 ms 20 ms 2 10.0.23.3 30 ms 30 ms 30 ms 3 8.8.8.8 40 ms 40 ms 40 ms第二跳直接显示10.0.23.3说明视频会议网段被强制送进了ISP-A。再用办公网段测试# R1 tracert -a 192.168.20.1 8.8.8.8输出里第二跳会变成10.0.24.4说明办公流量走了ISP-B链路。我还可以做一组对照实验加强理解先在R2上把指向R4的静态路由优先级改成比R3更低让路由表的主路径变成R4但保留PBR不动。你会发现视频会议从R1测试时仍然走R3——这就证明了PBR的优先级高于路由表查表结果。数据平面被策略接管控制平面怎么变都影响不了它。4.5 另一种PBR实现方式基于MQC的Traffic Policy如果你的需求不止是重定向还要同时做限速、报文统计、优先级标记传统PBR就不够用了。华为上更通用的做法是MQC# R2 traffic classifier video type hash if-match acl 3001 traffic behavior redirect-video redirect ip-nexthop 10.0.23.3 traffic policy pbr-video classifier video behavior redirect-video interface GigabitEthernet0/0/0 traffic-policy pbr-video inboundMQC方式的优势在于behavior里可以叠加多个动作比如重定向的同时还可以car限速、remark标记优先级、statistic统计而且可以通过display traffic policy statistics查看命中计数排错比传统PBR方便很多。缺点就是配置量稍大对于纯路径调度来说有点杀鸡用牛刀。我做实验的习惯是先用传统方式跑通逻辑再切到MQC方式感受差异两个都练一遍考试和面试的时候就不怕了。5. 排错避坑路由策略实验中最容易翻车的地方5.1 常见故障现象与根因速查下面这些故障我都真实踩过整理成速查表方便你对照排查故障现象可能原因排查命令路由策略过滤没生效前缀列表掩码长度写错display ip ip-prefixRoute-Policy全部路由都被拒绝漏写兜底permit nodedisplay route-policy路由被引入但属性没改匹配条件与路由属性不匹配display route-policyPBR配置了但流量不走指定路径策略应用到了出接口而不是入接口display ip policy-based-routePBR下一跳不生效next-hop不是直连地址display ip policy-based-routeOSPF Filter-Policy对内部路由无效用Filter-Policy过滤区域内路由display ospf lsdbtracert能看到路径但ping不通回程路由缺失或NAT没做display ip routing-table5.2 每一条故障背后的排查思路先说路由策略不生效的问题。配置完成后先看Route-Policy本身是否被协议引用——很多人在路由协议里写了route-policy但名字拼错或者漏引用策略根本没有被执行。用display route-policy看匹配计数是最好的办法如果node下显示还从未被匹配过那就要回头查路由协议方向的配置了。再说前缀列表掩码长度。曾经有人想做只放行8.8.8.0/24的匹配结果ip-prefix里写的是8.8.8.0没写掩码长度整个路由域内的所有路由全被匹配了。前缀列表如果不写掩码长度匹配范围是0到32位全匹配这在多数情况下不是你想要的。我建议所有前缀列表都显式写明掩码长度养成习惯。PBR方向的问题是重灾区。策略一定要应用在流量进入的接口而不是流量出去的接口。你在R2上想让内网流量强制走R3策略就应该放在R2的G0/0/0内网口而不是G0/0/1外网口。很多人在G0/0/1上配了策略半天不生效就是因为报文根本不会从G0/0/1进来。apply ip next-hop的直连要求也容易踩。华为传统PBR要求下一跳地址必须在直连网段内不能写一个需要跨多跳才能到达的地址。比如你在R2上写apply ip next-hop 10.0.23.3没问题如果写成10.0.23.3之外一个非直连地址PBR不仅不生效还可能把报文丢弃。5.3 三条值得刻在脑子里的经验第一Route-Policy的默认行为是拒绝一切未匹配的路由。所以当你只想抓一条路由并修改属性其余放行的时候必须显式加一个空的permit node做兜底route-policy TEST permit node 100不写任何if-match和apply的空节点就是匹配所有并放行。这个兜底节点在实网里能避免很多灾难性事故。我有一次在BGP环境里忘了加导致所有未命中路由被拒发整个路由表被掏空直接被叫去复盘。第二PBR和NAT的配合顺序要心里有数。如果你在出口路由器上同时做NAT和PBR报文到达设备后先做转发决策查PBR/路由表再做NAT转换。所以PBR里匹配的源地址一定是内网转换前的地址而不是NAT之后的公网地址。实验里如果你把ACL写成NAT后地址策略永远匹配不到。第三做路由策略实验一定要备份基线配置。模拟器还好说实网里一条route-policy写错影响的可能是一个省的业务。我在动手前都会用display current-configuration把配置导出来做完一步验证一步不追求一次性把所有策略都配完。小步快跑出了问题回退也容易。5.4 如果策略路由生效了但路径和预期不同怎么定位还有一种很隐蔽的情况策略路由已经生效但流量走的路径和预期不符。这时候先别怀疑PBR先确认是不是回程路径的问题。PBR只管去程回程流量如果被对端设备按路由表走到另一条链路就会造成去程走A、回程走B的往返不一致现象。很多人在R1上tracert看到第二跳是10.0.23.3但最终ping不通不是PBR的问题而是R3/R4回程没有指回正确的内网路径。我在R3和R4上配了默认路由指回R2这个细节必不可少。如果做的是严格的双出口对称场景回程路由、NAT规则、PBR三方面都要同时考虑缺一个环节都会导致业务异常。实验做到最后我建议你把所有配置从头到尾梳理一遍用display current-configuration把关键配置导出来自己对着配置讲一遍每个策略的作用路径。能把配置讲成一条完整的故事线——内网视频流量从R1出发到R2后被PBR匹配强制拐向R3同时R2在重发布时用Route-Policy只让8.8.8.8这条外部路由进入OSPF域——这个实验你才算真正吃透了。路由策略不是背命令是建立这种流量和路由在整张网上如何流动的画面感有了画面感遇到任何协议、任何厂商的设备你都能快速把思路映射到对应的配置上。
