1. 实验前先理清这两件事1.1 路由策略Routing Policy和策略路由PBR到底差在哪做“路由策略实验练习”最容易踩的第一个坑就是把“路由策略”和“策略路由”混为一谈。这俩名字太像了很多教材还喜欢放在同一章但它们的处理对象完全不同路由策略管的是“路由表里有哪些路由、路由怎么传递”策略路由管的是“数据包实际怎么走”。打个比方路由策略是一个“安检员”站在路由更新的必经之路上检查这条路由能不能进路由表、能不能发给邻居、能不能从一种协议引入到另一种协议。它操作的是一张张“路由清单”修改的对象是路由属性比如优先级、开销、标记不会去管单个数据包怎么转发。策略路由则像一个“交警”站在设备转发路径的十字路口直接对数据包下命令你从哪个接口进来的、你是这个网段的就给我走有线那条链路不用管路由表里下一跳是谁。实操中的区别也很直观。你在设备上配了一条过滤规则周围邻居的路由表发生变化、收不到某些网段了这是路由策略在“安检”而你让网段的用户上网走出口A、网段走出口B同一时间用户访问同一个网站却走了不同的物理链路这是策略路由在“指挥交通”。这个实验练习把两者都覆盖了我是推荐你这么做的先用一台路由器把过滤、重发布、属性修改这些“路由策略”玩明白再配置“PBR策略路由”做基于源地址的流量分流。顺序很重要先懂策略再做分流否则后面调不通时你根本分不清是路由通告的问题还是PBR优先级的问题。1.2 这个实验涉及的核心技术点这个实验练习需要你至少掌握五块内容ACL访问控制列表、前缀列表Prefix-List、路由策略工具华为叫Route-Policy思科叫Route-Map、路由重发布Redistribute、以及PBR的报文分类和下一跳设定。ACL和前缀列表都是“过滤器”但两者的出身不同ACL最早是为包过滤设计的用来匹配源地址、目的地址、协议和端口前缀列表是专门为路由匹配发明的按照IP前缀和掩码长度两个维度精确匹配路由条目还能用ge/le参数控制掩码范围。做路由策略实验时我的实战习惯是匹配路由优先用前缀列表匹配数据流优先用ACL这样符合各自的定位出问题时也更好排查。路由策略工具是这套实验的灵魂。华为环境下Route-Policy由if-match子句、apply子句和节点node组成每个节点内部又分permit和deny模式思科Route-Map则用match和set对应。节点之间按序号从小到大匹配匹配到哪个节点就执行哪个节点的动作不再往下走。这个“按序匹配、先到先得”的逻辑是整个路由策略实验最核心、也最容易被忽略的规则。PBR方面重点在于理解“接口方向”和“优先级”。传统路由是查路由表最长匹配PBR则直接按策略先匹配。华为设备的PBR可以用流策略traffic-policy traffic classifier实现也可以直接配policy-based-route思科则是在接口下挂route-map。无论哪种本质都是三件事流量分类、设定动作比如set ip next-hop、接口应用。2. 实验拓扑与规划2.1 拓扑设计三台路由器就能撑起全场路由策略实验我用的是最精简的三台路由器拓扑如果你在eNSP或者EVE-NG里搭5分钟就能完成三台设备环环相连中间没有任何多余链路。R1与R2直连R2与R3直连每台路由器都宣告一个自己的环回口网段再在两两之间的物理链路上规划一个网段让OSPF或IS-IS能在这个环境里跑起来也方便后面演示重发布和路由过滤。具体地址规划可以参考下面这张表拿走直接用设备接口IP地址说明R1GigabitEthernet0/0/010.0.12.1/24连接R2R1LoopBack0172.16.1.1/32模拟内网终端网段R2GigabitEthernet0/0/010.0.12.2/24连接R1R2GigabitEthernet0/0/110.0.23.2/24连接R3R2LoopBack0172.16.2.1/32模拟核心设备自身R3GigabitEthernet0/0/010.0.23.3/24连接R2R3LoopBack0172.16.3.1/32模拟远端服务端选择三台设备是有讲究的。两台路由器只能做单点直连没法完整演示“一台中间设备同时从两侧接收路由、再决定如何向两侧通告”的过程四台以上又会让实验复杂度上升排查难度变大初学者容易怀疑人生。三台的拓扑刚好把R2变成“中转站”你可以在R2上同时做路由接收过滤和路由通告过滤还能在R2上配置PBR让从R1来的流量通过不同路径转发一站全练完。2.2 IP与路由协议规划先跑通再说策略IP规划好后我先在R1、R2、R3上把基础接口地址全部配完然后启用OSPF让全网的路由先“裸奔”起来确保所有LoopBack网段都能互相Ping通。然后再关闭部分接口检查路由表或者只在R2和R1、R2和R3之间各建一个OSPF邻居让R1到R3的路径必须经过R2。裸奔的目的有二一是验证物理链路和接口配置没有低级错误二是为后面的过滤实验留下一个“过滤前状态”。做路由策略实验最大的忌讳就是“还没跑通就加策略”一旦策略加完不通你分不清是策略本身的问题、还是基础路由就存在问题。我见过太多学员在eNSP里R1和R3一直Ping不通查了半天策略最后发现是R2的OSPF没起来白白浪费一下午。协议选择上推荐用OSPF因为它收敛快、邻居状态好排查display ospf peer这条命令一眼就能看出邻居是否Full。当然如果你想练得更深同样拓扑下换成IS-IS或BGP也完全成立BGP环境下还能继续玩AS-Path属性过滤和团体属性进阶空间很大。3. 路由策略实验控制路由的“进”与“出”3.1 前缀列表路由过滤的最佳搭档前面的准备完成后开始第一个正式实验让R3只能从R2学到部分网段。比如R2上有三条核心路由我现在想让R1宣告的172.16.1.0/24网段通过但把R1的192.168.1.0/24网段过滤掉就轮到了前缀列表出场。先在R2上定义IP前缀列表命令如下# 在R2上配置 ip ip-prefix EXT-ONLY permit 172.16.1.0 24这条命令的意思是只允许精确匹配172.16.1.0/24的路由。如果想让子网掩码范围放宽可以用ge和le参数ip ip-prefix EXT-ONLY permit 172.16.0.0 16 ge 20 le 28这条的含义是匹配前缀为172.16开头的网段掩码长度从20位到28位之间都算匹配也就是172.16.16.0/20、172.16.32.0/24这类网段都会命中而172.16.0.0/16本身因为掩码小于20就不满足条件。这个特点是用ACL很难实现的因为ACL配通配符掩码时没法表达“掩码范围”的语义前缀列表天生就是干这个的所以路由匹配场景我永远优先用它。有了匹配工具接下来把这个前缀列表追加到OSPF协议的入方向过滤上让该策略对从R3方向进入R2的路由生效控制路由接收动作按计划执行# 在R2的OSPF进程下配置 ospf 1 filter-policy ip-prefix EXT-ONLY import配置完成后在R2上执行display ip routing-table你会看到R3环回口的路由悄然消失R1的环回口路由依旧存在。再把R3上的OSPF配置修改过滤通告方向的场景通过filter-policy ip-prefix EXT-ONLY export实现或者直接在R1与R2的二层链路上用silent-interface接口命令配合过滤让邻居关系断开。这里有一个关键的坑必须提醒不要在R2上对OSPF进程做全局的filter-policy export除非你非常清楚OSPF的LSA泛洪机制。因为OSPF是链路状态协议邻居关系建立后过滤export实际上只是“过滤路由表项进入路由表”LSA依然会通告出去邻居学到的条目可能仍然存在。这也是为什么做路由策略实验时基础理论要先过关不然你会拿着display ospf lsdb命令看半天也理解不了“为什么我过滤了但LSDB里还有”。3.2 Route-Policy重发布实验把直连路由批量引进OSPF第一关通过后加大一点难度在R2上把直连路由包括LoopBack重发布进OSPF同时只允许特定网段被发布其他网段一律拦住。华为用Route-Policy配合重发布命令实现思科用Route-Map Redistribute实现思路完全一致。先在R2上定义ACL抓取需要的网段# 在R2上配置 acl number 2000 rule 5 permit source 172.16.2.0 0.0.0.255 rule 10 deny再定义Route-Policy# 在R2上配置 route-policy DIRECT-TO-OSPF permit node 10 if-match ip address acl 2000最后在OSPF进程下引入直连路由应用这个策略# 在R2的OSPF进程下配置 ospf 1 import-route direct route-policy DIRECT-TO-OSPF配置完成后在R1上看这台R2发布过来的路由你会发现只有172.16.2.0/24这一个“直连网段”被引入R2物理接口的网段如10.0.23.0/24反而没有被发布。为什么原因在于ACL匹配的是路由前缀而R2的直连路由包含物理接口网段和LoopBack网段你只允许了LoopBack网段物理接口网段在rule 10里被deny了策略生效后续动作停止。这个实验真正想让你理解的是“重发布的方向性”。路由策略是分方向的重发布进OSPF时方向是“从其他协议进程流向OSPF进程”在R1上看到的条目就是R2过滤后的结果重发布出OSPF则在其他方向生效。实际操作时注意在R1上执行display ospf routing和display ip routing-table对比查看前者看OSPF数据库里的LSA后者看真正安装进路由表的条目两者一致才能说明过滤成功不一致就检查filter-policy的位置是否放错了。3.3 控制路由通告在R2上“按下”不需要的路由重发布做完再回来做一个反向练习在R2上用Route-Policy的apply子句修改路由的属性然后专门观察R3收到后的表现。比如把R1的环回口路由在重发布过程中打个“标签”然后把开销改成50# 在R2上配置 acl number 2001 rule 5 permit source 172.16.1.0 0.0.0.255 route-policy SET-METRIC permit node 10 if-match ip address acl 2001 apply cost 50 apply tag 100 ospf 1 import-route ospf route-policy SET-METRIC这里注意如果你在R2上把R1的OSPF路由通过import-route ospf的方式再引入一遍可能形成路由反馈这在OSPF中默认是不允许的。更稳妥的做法是在重发布直连或静态路由时应用这个Route-Policy或者把实验换成在R2上同时运行OSPF和IS-IS再把一个协议的路由重发布进另一个协议这样既能体现属性修改又不会出现自环式的路由混乱。我建议你在这个环节做一个“双协议重发布”的组合实验R1、R2跑OSPFR2、R3跑IS-ISR2上用Route-Policy把OSPF引入的路由重发布到IS-IS时利用apply cost修改开销值反过来IS-IS重发布进OSPF时if-match匹配上某条路由再apply tag标记。在R2和R1上分别查看路由表就能直观看到同一前缀因为属性变化产生了不同的选路结果。4. PBR策略路由实验让流量不走寻常路4.1 策略路由和路由策略在实验中的实战区别前面实验都在“改路由”接下来换挡做“改转发”。PBR策略路由的原理其实很简单当数据包进入设备时先按策略匹配匹配上了就按策略指定的下一跳转发不再查找路由表匹配不上才回落回正常的路由表转发路径。这里的“先”和“优先级”是整个PBR的灵魂。我用一个最经典的实验场景来说明R1下面接了两台PC网段分别是192.168.10.0/24和192.168.20.0/24R2上连着两条出口链路模拟两条链路分别接R3和R4我现在要求“网段的流量走R3出局网段的流量走R4出局”。如果是传统路由无论哪个网段访问同一个目标选路结果都一样出口只有一个PBR就是为了打破这种“一视同仁”的局面。华为设备上配置PBR的方式主要有两种。老手法是接口下直接应用policy-based-route新手法是基于流策略的traffic-policy traffic classifier后者更符合现代设备的转发架构也更便于你日后对接防火墙、负载均衡的配置习惯。思科对应的就是ip policy route-map。做这个实验时我推荐你先把traffic classifier的写法练熟因为它在实际项目中是主流。4.2 基于源地址的PBR分流一个命令看清流量走向下面是华为设备配置PBR的具体命令我先用基于流策略的写法示范先在R2上定义流分类匹配源地址为192.168.10.0/24的流量# 在R2上配置 acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 traffic classifier VOICE if-match acl 3001再定义流行为指定下一跳# 在R2上配置 traffic behavior TO-R3 redirect ip-nexthop 10.0.23.3最后把流分类和流行为绑定成流策略并应用到接口入方向# 在R2上配置 traffic policy PBR-VOICE classifier VOICE behavior TO-R3 interface GigabitEthernet0/0/0 traffic-policy PBR-VOICE inbound配置完成后的验证命令是关键。我在R2上执行display traffic policy applied-record查看策略命中情况再在R1上分别Tracert两个不同网段的源地址访问同一个目标观察路径差异。通过这个实验你会看到一个很有意思的现象流量在第一跳R2就被“拐弯”了最终路径完全由PBR决定网络上所有传统路由选路规则都退居二线。4.3 PBR的调试思路为什么流量不按策略走PBR实验最常见的现象是“配置完成后策略一点效果都没有”所有流量还是按老路径转发。这个坑90%的初学者都踩过而且踩进去之后感觉天都塌了。我列一下完整的排查步骤每一步都照着做第一步查接口方向。PBR只能应用在入方向你如果配在出方向华为设备会直接报错但你别以为报错就停了有些版本会静默失效流量照走策略无感很多人就在这一步卡住。确认接口inbound命令敲进去了。第二步查匹配条件。用display traffic classifier statistics查看分类器的命中计数如果命中计数为0说明ACL没有匹配到流量这时候去看ACL里规则的顺序和通配符掩码最常见的问题是源网段子网掩码换算错了把/24写成了0.0.255.255导致匹配范围比预期大了无数倍。第三步查下一跳。redirect ip-nexthop指定的地址必须是路由器本地直连路由表中的可达地址。如果你指定的下一跳在路由表里没有条目PBR不会报错而是把所有流量都“扔掉”表现为断网。这比策略失效还恐怖因为外部表现为链路中断你会先去查链路、查接口根本想不到是PBR在作祟。第四步确认PBR和路由表的优先级顺序。设备和转发流程中入方向PBR的优先级高于路由表所以它是一把“先斩后奏”的利器但我还是建议你在设计中尽量保持“策略兜底路由为主”的思路让大部分流量走正常路由PBR只处理那10%需要特殊分流的场景这样故障时好回退、好排查。5. 验证方法与排查技巧实录5.1 常用验证命令一眼看出策略是否生效整套实验做完验证是最后一道工序也是考试一般不会明说却最值钱的部分。华为设备上我常用的命令是这些建议你全部敲一遍并记录输出对比# 查看路由表是否安装预期路由 display ip routing-table # 查看ACL匹配计数 display acl 3001 # 查看流策略应用记录和命中次数 display traffic policy applied-record display traffic classifier statistics # 查看Route-Policy内部匹配情况 display route-policy # 查看OSPF协议路由和LSDB状态 display ospf routing display ospf lsdb这条命令组合的核心价值在于“从匹配到落地全程可观测”。比如你在Route-Policy里配了if-match和apply但不知道究竟匹配了哪几条路由、应用了哪个属性display route-policy会告诉你每个节点的匹配状态display ip routing-table会告诉你最终结果两层一对比问题锁定就快了。另外强烈建议你养成抓包的习惯。PBR实验出问题时用Wireshark或华为的报文统计功能在R2的入接口和出接口各抓一次包对比报文的IP头——尤其注意源地址和下一跳MAC地址的变化很多时候策略明明命中了但因为流量被正常转发只是你没看到效果。抓包的直观性远超命令行一次失败实验配上抓包记录排查效率翻倍。5.2 常见问题速查表路由策略实验的“避坑手册”我把这些年做实验和带新人时踩过的坑整理成一张速查表贴在工位上每次做实验前扫一眼至少能帮你省下大半天的排查时间现象可能原因排查动作过滤策略配了但路由还在filter-policy位置放错export/import方向反了或ACL/前缀列表规则写反display acl查看匹配计数核对方向Route-Policy匹配不到路由ACL的deny规则写在了permit前面或节点序号跳跃导致匹配中断display route-policy逐节点确认把ACL按5、10、15递增编号PBR不生效接口方向配错、流分类匹配为空确认inbound方向查看traffic classifier statisticsPBR生效后流量直接不通redirect的下一跳不可达ping下一跳检查路由表是否有直连条目OSPF过滤后邻居DB仍看到路由对链路状态协议export过滤只影响路由表不影响LSA用silent-interface或对LSDB层面做设计调整路由重发布后出现环路双点重发布未做属性控制路由被反复引入给重发布路由打tag再用filter-policy拒绝环回这里特别把“OSPF过滤后LSDB仍能看到路由”单独拎出来说。链路状态协议的特点是“所见即所得”邻居间同步的是LSDB不是路由表你在入方向做filter-policy禁止的只是把某条路由“安装”到本地路由表LSA依然会收到、依然会存进LSDB。实验时如果你只看了display ospf lsdb就以为过滤失败可能还要再花半个小时怀疑人生。这个知识点在BGP里同理理解“路由表”和“协议数据库”是两回事对以后的排障非常有帮助。5.3 进阶扩展路由策略还能这么玩基础实验跑通后如果你想继续深挖有几个方向我强烈推荐。第一个是BGP环境下的路由策略一台路由器连接两个AS通过Route-Policy控制引入的AS路径、设置LOCAL_PREF和MED属性然后观察BGP选路的变化这套能力在大规模网络中非常实用。第二个是双出口环境下把PBR和NAT结合内网两个网段分别走两条出口链路并分别做源NAT实现出口负载均衡和故障快速切换这也是中小型企业网络的常见需求。第三个方向是策略打标签后联动其他技术。我最推荐的是把路由策略实验和“路由引入加Tag、再用Tag做过滤”结合起来这也是生产环境中最经典的“一次打标、多处引用”套路。先给特定路由打个internal tag然后在边界设备上再用if-match tag过滤只放行带标签的路由后续要调整策略时只需要改一个标签不用翻遍整个设备集群改几十条ACL。这个思路会让你真正理解“路由策略不只是写几行命令而是在设计一套控制逻辑”。我个人在实际操作中的体会是路由策略和PBR这类实验不要指望“配完就完”更不要指望“照抄命令就能懂原理”。每次实验前花十分钟想清楚这个策略要解决什么问题——是过滤路由、修改属性、还是重定向流量实验后把display命令的输出截图保存再写一句“为什么”的注释积累两周后你会发现排障速度和理解深度都上了一个台阶。最后再分享一个小技巧所有实验尽量先用eNSP或EVE-NG这类模拟器反复跑通再考虑在物理设备上落地模拟器里随便怎么折腾都不会有现实代价但你在模拟器里养成的“先验证后上线”的习惯到了生产环境里是真的能救命的。
