做路由策略实验的人很多但真正把“路由策略”和“策略路由”掰扯清楚、能把实验做到位的人说实话不多。我去年做一次割接演练时就因为在过滤路由和引导流量这两个需求上选错了工具结果明明是同一张拓扑调了大半天才发现思路从一开始就偏了。这篇文章就是基于那次经历以及之后我反复搭建的路由策略实验练习环境把完整的实验思路、配置细节、验证方法和踩坑点全部梳理出来。适合刚学完基础路由协议、准备上手动手做实验的网工也适合那些理论上懂个大概、但一敲命令就找不到北的朋友。顺便说一句这几年大家都在提PBR策略路由这确实是热点但如果你连Route-Policy和PBR各自的适用场景都没分清楚盲目跟风上策略路由反而会把组网弄得极其复杂。所以这篇文章不只是操作手册更是一份决策手册。1. 路由策略与策略路由实验前必须想明白的两条路先说一个最常见的误解很多人以为路由策略就是策略路由反正都是策略差不多。但我可以负责任地告诉你这两个东西解决的是完全不同的两类问题实验设计思路也完全不同。路由策略Route-Policy / Filter-Policy的核心动作是过滤和修改属性。它管的是路由表本身比如我通过BGP从邻居学到100条路由我只想留10条进路由表其他90条扔掉或者我学到的路由cost是50我想把它改成200再去参与选路。这时候用路由策略。策略路由PBRPolicy-Based Routing的核心动作是改路但它不管路由表它直接绕过路由表基于流量的特征源地址、目的地址、协议、端口等强行指定下一跳。最典型的场景是我有两条出口链路想按照源IP来分流比如办公区走运营商A服务器区走运营商B。传统的路由表只能按目的地址查做不到按源地址选路这时候PBR就登场了。打个比方。路由策略就像公司HR在筛简历收到的应聘邮件路由先过一遍过滤器符合条件permit的留下进入人才库路由表不符合的deny直接丢弃还可以给留下的简历打上不同的等级标签修改属性。策略路由则像前台接待员他来办事不看你的简历直接根据你今天穿什么颜色的工牌流量的源地址、端口特征把你引导到对应的办事窗口。简历内容路由表根本不重要。这个区别直接决定了实验拓扑怎么搭。如果是练路由策略你得搭一个能传播大量路由的环境核心观察点是路由表里到底进了哪些条目。如果是练PBR你得搭一个多出口的环境核心观察点是流量实际走了哪条物理链路。我见过不少实验练习者拓扑里就两台路由器直连每条链路就两三条路由然后试图练Route-Policy的过滤——能练但效果很差因为路由太少permit/deny之后看不出区别几个节点匹配的感觉完全建立不起来。所以实验环境的设计要贴合你想验证的那条原理。2. 实验环境搭建用EVE-NG还是真机拓扑怎么画工欲善其事必先利其器。路由策略实验的载体我首推EVE-NG其次GNS3要是条件所限用华为eNSP也没问题。真机当然也行但真机动不动就是三层设备端口少、价格高做多路由器互联实验很受限制。我用的是EVE-NG跑华为vEOS镜像AR1、AR2、AR3 三台Cloud连接虚拟主机。拓扑如下R1模拟局域网内部路由器连接两个业务网段A192.168.10.0/24和B192.168.20.0/24R2核心路由器同时连接R1和两个上游出口——ISP1方向模拟运营商A和专线方向模拟总部专线R3模拟ISP1侧路由器提供一些公网路由和一个外网服务器网段这个拓扑的精妙之处在于R2正好处在一个多路由来源多出口的位置既能练路由策略从R3学到的路由怎么过滤、怎么改属性又能练PBR来自R1不同网段的流量如何分别走两条出口。一张拓扑两个实验共用省事。在EVE-NG里我习惯给设备配好管理地址通常是192.168.100.x用SecureCRT批量打开窗口。这一步看起来很基础但实际做实验时窗口多了很容易乱我的技巧是把每台设备的标签写清楚比如R2-CORE、R3-ISP1“R1-LAN”窗口底色也设置不同一眼就能对上。实验前先把三台路由器的基础配置完成接口IP、loopback、OSPF或者ISIS把二个网段宣告进核心。R1和R2跑OSPFR2和R3之间跑BGP模拟运营商间互联这样能同时体会动态协议里路由策略的用法。注意R2到R3之间起BGP是为了后面实验BGP路由策略比如AS号过滤、cost修改如果你只练PBR那R2和R3之间跑静态路由也行灵活调整。拓扑完成后第一件事不是急着配策略而是先看没有任何策略时流量怎么走。这一步很关键你得先有一个干净的baseline知道默认路径长什么样后面策略下发后才有对比。从R1去往R3方向的服务器默认走哪条路取决于R2的路由表里哪条路由更优。如果R2到ISP1和到专线的两条路由都是直连线路OSPF和BGP在选路时会按协议优先级、cost来定最终大概率是走OSP或BGP学到的某一条。这个默认行为记录下来后面所有实验的对比都以这个为基准。3. 实验一用IP前缀列表和Route-Policy过滤路由先把路由表管起来这个实验的目标很朴素R2从R3通过BGP学到了一批路由我们只允许其中一部分进入R2的路由表或者在学习的同时修改它们的cost和community值。这属于典型的路由策略Routing Policy范畴。3.1 为什么用ip-prefix而不是ACL来匹配路由很多人做路由过滤一上手就写access-list这是个习惯性问题。ACL在设计之初主要是匹配报文用的对路由条目的匹配支持并不是先天优势尤其是在匹配前缀长度精确范围时ACL极其别扭。而IP前缀列表ip ip-prefix天生就是干这个的它支持匹配某前缀匹配掩码长度范围我们看一个例子[R2] ip ip-prefix ALLOW index 10 permit 192.168.10.0 24这条命令的意思是只匹配前缀192.168.10.0、且掩码长度为24位的路由条目。如果想匹配掩码在24到28之间的路由可以写[R2] ip ip-prefix ALLOW index 10 permit 192.168.10.0 24 less-equal 28这里的less-equal 28就限定了掩码长度上限。ACL如果要实现同样的功能你得针对每个掩码长度写一条rule繁琐且容易漏。所以我的建议是路由匹配统一走ip-prefixACL留给PBR或数据流匹配用。3.2 Route-Policy的结构化配置node与if-match的关系配置Route-Policy时华为的语法让我一度很困惑后来想通了就不难了。它的核心结构是节点node匹配条件if-match动作applyroute-policy ONLY-A permit node 10 if-match ip-prefix ALLOW apply cost 100这里有几个点必须说清楚node 10不是优先级数值而是节点的编号用于排序。匹配时从最小的node开始从小到大逐个检查。匹配到node 10且条件是permit就执行apply并结束。permit/deny的作用和ACL不同。在Route-Policy中permit表示允许这条路由通过策略deny表示拒绝这条路由进入下一环节比如不进路由表。但注意如果某个node是deny而且没有匹配到它之前的所有节点那路由会被拒绝。如果在一个node里写了if-match但路由不匹配该条件策略不会直接结束而是跳到下一个node继续判断。这个跳转行为很多人第一次做实验时会忽略导致为什么写了permit node 10之后其他路由也进去了的困惑。我们把实验场景拆开来看。假设R2从R3收到如下路由192.168.10.0/24192.168.20.0/24192.168.30.0/2410.1.0.0/16我们只想让192.168.10.0/24和192.168.20.0/24进路由表其余都拒绝。配置如下[R2] ip ip-prefix LAN10 permit 192.168.10.0 24 [R2] ip ip-prefix LAN20 permit 192.168.20.0 24 [R2] route-policy ONLY-LAN permit node 10 [R2-route-policy] if-match ip-prefix LAN10 [R2-route-policy] route-policy ONLY-LAN permit node 20 [R2-route-policy] if-match ip-prefix LAN20注意这里我写了两个node都是permit。如果路由匹配node 10就通过apply没有写所以不修改属性如果不匹配node 10就跳到node 20再判断如果两个node都没匹配上这条路由会被隐式的deny拒绝。这就是华为策略末尾默认deny all的规则。所以不需要额外写一个deny node。在BGP场景中调用方式是在peer视图下[R2-bgp] peer 10.0.3.3 route-policy ONLY-LAN import这样R2从R310.0.3.3收到的所有路由都会经过该策略。实验时你可以用display bgp routing-table观察过滤前后的路由数量变化用display ip routing-table看最终进路由表的条目。3.3 修改路由属性从过滤到影响选路路由策略的另一个大用途是修改路由属性。比如我希望从R3学到的一条路由cost变成500以便让R1日后选路时不走这条路径但又不希望完全删除它——这时候可以用apply cost。[R2] route-policy SET-COST permit node 10 [R2-route-policy] if-match ip-prefix LAN10 [R2-route-policy] apply cost 500如果是在BGP里还能改local-pref、MED、community等。实验时我建议三件套都试一遍apply cost 500影响IGP选路OSPF里对应改costapply local-preference 200影响BGP选路越大越优默认100apply community 100:200给路由打团体标签为下游设备做二次策略匹配提供依据做完修改动作后在R2上display bgp routing-table 192.168.10.0 24能看到local pref等属性变化这就是策略生效的直接证据。写实验报告时这些前后对比数据非常有说服力。4. 实验二PBR策略路由实战从看路由表到强行改路径这一部分就是热搜词里提到的PBR策略路由。PBR的核心概念我已经在第1部分讲过了现在直接进入实验。沿用上面的拓扑R1下面带着网段A192.168.10.0/24和网段B192.168.20.0/24R2连着两条出口一条走10.0.2.2ISP1方向一条走10.0.3.2专线方向。需求网段A的所有流量走ISP1方向网段B的所有流量走专线方向。用传统路由表实现吗不可能因为传统路由表里查目的地址A和B访问同一个目的地址下一跳必须相同。只有PBR能实现这种基于源地址的选路。4.1 华为的流分类三板斧ACL 流分类 流行为华为设备上做PBR通常用traffic classifier流分类 traffic behavior流行为 traffic policy流策略三位一体。步骤拆开看其实不复杂第一步用ACL识别源网段[R2] acl number 3001 [R2-acl-adv] rule 5 permit ip source 192.168.10.0 0.0.0.255 [R2-acl-adv] acl number 3002 [R2-acl-adv] rule 5 permit ip source 192.168.20.0 0.0.0.255这里用高级ACL匹配源地址0.0.0.255是通配符相当于只关心前三段。第二步定义流分类Classifier[R2] traffic classifier C-A [R2-classifier-C-A] if-match acl 3001 [R2-classifier-C-A] traffic classifier C-B [R2-classifier-C-B] if-match acl 3002第三步定义流行为Behavior——指定下一跳[R2] traffic behavior B-ISP1 [R2-behavior-B-ISP1] redirect ip-nexthop 10.0.2.2 [R2-behavior-B-ISP1] traffic behavior B-MPLS [R2-behavior-B-MPLS] redirect ip-nexthop 10.0.3.2注意这里redirect ip-nexthop的地址必须保证是直连可达的否则PBR无法解析下一跳这也是实验中最容易翻车的地方下一跳写了一个非直连地址策略配置了却不生效。第四步配置流策略Policy并应用到接口[R2] traffic policy PBR-POLICY [R2-policy-PBR-POLICY] classifier C-A behavior B-ISP1 [R2-policy-PBR-POLICY] classifier C-B behavior B-MPLS [R2] interface GigabitEthernet0/0/0 [R2-GigabitEthernet0/0/0] traffic-policy PBR-POLICY inbound关键点来了PBR的应用方向是inbound还是outbound这取决于流量从哪个接口进入设备。我的拓扑中R1的流量从R2的GigabitEthernet0/0/0进入所以在那个接口上应用inbound方向的策略。如果说反了策略永远不会被匹配。这个细节我见过太多人栽过跟头写实验报告时一定要把这个方向搞明白。4.2 思科路由器的PBR对照route-map的简洁风格如果你手边的是思科设备实现同样的需求配置会更简洁interface gigabitethernet0/0 ip policy route-map PBR-POLICY ! access-list 101 permit ip 192.168.10.0 0.0.0.255 any access-list 102 permit ip 192.168.20.0 0.0.0.255 any ! route-map PBR-POLICY permit 10 match ip address 101 set ip next-hop 10.0.2.2 route-map PBR-POLICY permit 20 match ip address 102 set ip next-hop 10.0.3.2思科的route-map逻辑和华为的traffic policy逻辑异曲同工但语法上route-map在一个节点里同时有match和set语义更像如果匹配条件那么就执行动作。思科的策略同样要应用到接口的inbound方向。如果是H3C设备PBR的NQA联动和递归下一跳很出名配置风格又略有不同但核心思路都是匹配特征指定下一跳。4.3 PBR不生效的三个典型原因这个实验我做过十几遍每次都有学生或同事问为什么我配置了策略流还是按原来的路走我很确定问题基本出在这三处下一跳不可达redirect的地址必须是直连路由可解析的设备不支持把流量扔给一个它无法路由到达的下一条。应用方向错误PBR应用在数据流进入设备的那个接口的inbound方向不是出接口方向的outbound。有些人的理解是流量要往ISP走那就应该在去往ISP的那个接口上做这个理解是错的。PBR必须在流量刚进设备、还没查路由表之前做决定。ACL匹配的源方向搞反了在R2接口的inbound方向做PBRACL里的source应该是来自R1的源地址例如192.168.10.0/24而不是目的地址。如果你写成了destination指向某个公网网段大概率匹配不到。还有一个容易被忽略的问题PBR的匹配优先级是顺序匹配先到先得。如果你的ACL 3001写成了一条permit ip any any那后面的3002永远不会被查。所以规则顺序一定要小心。4.4 PBR实验的验证方法别只盯着ping策略下发后怎么验证真的走了指定链路我推荐至少三种手段联合验证第一traceroute路径法。从R1发起traceroute到10.0.2.2或一个远端网段观察路径中R2之后的下一跳是谁。如果网段A的流量经过10.0.2.2而网段B经过10.0.3.2基本能确认PBR生效。但要注意traceroute不一定能直观看到R2之后的第二跳有时只显示第一跳需要在R2上开启icmp超时消息的发送权限。第二display traffic policy statistics。在R2上执行[R2] display traffic policy statistics inbound interface GigabitEthernet0/0/0正常能看到C-A和C-B两个分类的匹配计数在增长。如果某个分类计数一直是0说明ACL没匹配成功。第三接口计数器法。如果两个出接口都有计数功能在R1上大流量ping或打流同时观察R2去往两个出口方向的接口的Input/Output bytes变化。哪个接口的计数器涨得快流量就走哪。这是最无语的物理层验证。5. 实验三PBR结合路由策略的混合场景实现先选路再改路题目叫路由策略实验练习那我把两个内容交叉起来做一个更有代表性的综合实验。需求是这样网段A的流量走ISP1方向并且在ISP1方向学到的某条路由上我们要把它的cost调高使网段A流量到达R3后也不被认为是一条环路或较优路径。这种混合场景在真实组网里很常见既要有PBR按源地址分流又要用Route-Policy影响某个方向上的路由优劣。两个策略是不同层面的PBR在转发平面工作Route-Policy在控制平面路由协议工作。实验步骤可以分两块写块一PBR分流和实验二相同把网段A送去ISP1。块二在R2与R3的BGP邻居上应用route-policy对从R3方向学到的10.0.0.0/22之类的路由打上MED 200或community标记。这样一来即使ISP1方向和专线方向同时学习到10.0.0.0/22R2也会因为MED值不同而选择更低cost的一侧作为回程路径。[R2] route-policy FROM-ISP1 permit node 10 [R2-route-policy] if-match ip-prefix TO-ISP [R2-route-policy] apply med 200 [R2-bgp] peer 10.0.3.3 route-policy FROM-ISP1 import这里的IP前缀列表TO-ISP先定义好要匹配的10.0.0.0/22。综合验证要点在主机侧 ping 服务器观察来回路径的对称性在R2上用display bgp routing-table查看MED对比同时观察R2不同接口的流量计数说实话这个混合场景一出来才算真正把路由策略和策略路由融会贯通了。很多面试题问得天花乱坠其实就是考察你有没有跑通这种左右互搏的脑子。6. 命令之外的辅助工具与调试技巧让实验看得更透实验做得好不好往往不在配置本身而在调试手段。我总结几个必须掌握的调试和排障技巧这是普通教科书里不爱仔细讲的部分。6.1 华为的debug和display组合拳display ip routing-table protocol bgp只看BGP学到的路由快速确认过滤结果。display bgp routing-table statistics看BGP路由总数和过滤情况能直观看到策略生效前后条数差异。debug ip packet华为为debug ip packet思科为debug ip policyPBR场景下打开debug后能看到匹配ACL的报文动作。华为的debug ip packet输出很冗长我建议结合ACL做过滤式debug只关注特定源地址R2 debugging ip packet acl 3001这样只会打印源地址是192.168.10.0/24的报文日志量小很多。display policy-based-route早期版本叫display ip policy-based-route查看PBR配置和匹配次数。这个命令在某些版本上有差异建议先display traffic policy查一下全局配置状态。6.2 抓包用Wireshark实锤转发路径如果你想确认PBR真的把流量转给了某个具体的下一跳更硬的证据是抓包。在EVE-NG的链路两端挂Wireshark或者用Cloud连接真实网卡抓取ICMP报文看源目的IP对不对看MAC地址是否下一跳设备的MAC。我记得有一次调试一个PBR不生效的问题display计数显示匹配了traceroute结果也对不上后来用抓包一看下一跳虽然指对了但出接口因为某种原因又做了一次路由表查询结果绕了一大圈。这类看似生效实则没生效的隐性bug只能靠抓包来确认数据面的真实走向。6.3 用静态路由保底给PBR一个兜底出口在做PBR实验的拓扑里我强烈建议先配置好静态默认路由或OSPF/BGP兜底路由确保在没有启用PBR时环境也能通。然后再下发PBR策略覆盖特定流量。这种先全通再局部改路的渐进式验证思路能极大降低实验排障难度。策略配错了回退也比较简单——移除traffic-policy即可。7. 延伸思考从网络实验到Linux策略路由的相通性如果你把路由策略实验练熟了会发现Linux服务器上的策略路由逻辑和它几乎一模一样只是名字不同。Linux用ip rule定义策略rule用ip route ... table X定义路由表table。比如实现来自10.0.0.0/8的流量走table 10的默认路由ip rule add from 10.0.0.0/8 lookup 10 ip route add default via 10.1.1.1 dev eth1 table 10这条rule和华为的traffic classifier C-A if-match acl 3001本质上是同一个思路先匹配流量特征再指定转发规则。我建议学习者在做完网络设备实验后找一台Linux虚机把同样需求实现一遍。跨平台之后你会发现所有策略类技术的底层思维是一致的分类classification 动作action 应用位置application point。把握住这个三角任何厂商的文档都能举一反三。8. 实验报告怎么写让一张拓扑讲清三类结论最后聊一个容易被忽视的问题——实验记录。很多人实验做完截图一截就完事了但真正有价值的实验报告应该把为什么写清楚。我的习惯是每个实验记录三件事策略配置前后的路由表/bgp表对比把display结果贴出来标注出变化条目这是证据链。一项原始需求对应一条配置逻辑比如让A网段走ISP1对应的就是ACL 3001里source是A网段、behavior把nexthop指向10.0.2.2。这样事后回看每个配置都有据可查。验证方法及结果截图至少包含display policy统计、traceroute路径、接口计数三张图。数字对比是实验报告的灵魂没有验证的实验等于白做。另外每次实验结束时我都会把配置清理干净重新回到baseline状态再开始下一个实验。保持每次实验的单变量原则——只改动一个策略因素其他都不变——这样得到的结论才可信。这套路由策略实验练习的完整流程走下来你基本就拥有了独立设计、调优和排障的能力。别再对着厂商白皮书死记硬背了拓扑搭起来命令敲下去你才能真正理解策略的路由世界是什么样。
路由策略与策略路由实验：概念、配置与排障实战
做路由策略实验的人很多但真正把“路由策略”和“策略路由”掰扯清楚、能把实验做到位的人说实话不多。我去年做一次割接演练时就因为在过滤路由和引导流量这两个需求上选错了工具结果明明是同一张拓扑调了大半天才发现思路从一开始就偏了。这篇文章就是基于那次经历以及之后我反复搭建的路由策略实验练习环境把完整的实验思路、配置细节、验证方法和踩坑点全部梳理出来。适合刚学完基础路由协议、准备上手动手做实验的网工也适合那些理论上懂个大概、但一敲命令就找不到北的朋友。顺便说一句这几年大家都在提PBR策略路由这确实是热点但如果你连Route-Policy和PBR各自的适用场景都没分清楚盲目跟风上策略路由反而会把组网弄得极其复杂。所以这篇文章不只是操作手册更是一份决策手册。1. 路由策略与策略路由实验前必须想明白的两条路先说一个最常见的误解很多人以为路由策略就是策略路由反正都是策略差不多。但我可以负责任地告诉你这两个东西解决的是完全不同的两类问题实验设计思路也完全不同。路由策略Route-Policy / Filter-Policy的核心动作是过滤和修改属性。它管的是路由表本身比如我通过BGP从邻居学到100条路由我只想留10条进路由表其他90条扔掉或者我学到的路由cost是50我想把它改成200再去参与选路。这时候用路由策略。策略路由PBRPolicy-Based Routing的核心动作是改路但它不管路由表它直接绕过路由表基于流量的特征源地址、目的地址、协议、端口等强行指定下一跳。最典型的场景是我有两条出口链路想按照源IP来分流比如办公区走运营商A服务器区走运营商B。传统的路由表只能按目的地址查做不到按源地址选路这时候PBR就登场了。打个比方。路由策略就像公司HR在筛简历收到的应聘邮件路由先过一遍过滤器符合条件permit的留下进入人才库路由表不符合的deny直接丢弃还可以给留下的简历打上不同的等级标签修改属性。策略路由则像前台接待员他来办事不看你的简历直接根据你今天穿什么颜色的工牌流量的源地址、端口特征把你引导到对应的办事窗口。简历内容路由表根本不重要。这个区别直接决定了实验拓扑怎么搭。如果是练路由策略你得搭一个能传播大量路由的环境核心观察点是路由表里到底进了哪些条目。如果是练PBR你得搭一个多出口的环境核心观察点是流量实际走了哪条物理链路。我见过不少实验练习者拓扑里就两台路由器直连每条链路就两三条路由然后试图练Route-Policy的过滤——能练但效果很差因为路由太少permit/deny之后看不出区别几个节点匹配的感觉完全建立不起来。所以实验环境的设计要贴合你想验证的那条原理。2. 实验环境搭建用EVE-NG还是真机拓扑怎么画工欲善其事必先利其器。路由策略实验的载体我首推EVE-NG其次GNS3要是条件所限用华为eNSP也没问题。真机当然也行但真机动不动就是三层设备端口少、价格高做多路由器互联实验很受限制。我用的是EVE-NG跑华为vEOS镜像AR1、AR2、AR3 三台Cloud连接虚拟主机。拓扑如下R1模拟局域网内部路由器连接两个业务网段A192.168.10.0/24和B192.168.20.0/24R2核心路由器同时连接R1和两个上游出口——ISP1方向模拟运营商A和专线方向模拟总部专线R3模拟ISP1侧路由器提供一些公网路由和一个外网服务器网段这个拓扑的精妙之处在于R2正好处在一个多路由来源多出口的位置既能练路由策略从R3学到的路由怎么过滤、怎么改属性又能练PBR来自R1不同网段的流量如何分别走两条出口。一张拓扑两个实验共用省事。在EVE-NG里我习惯给设备配好管理地址通常是192.168.100.x用SecureCRT批量打开窗口。这一步看起来很基础但实际做实验时窗口多了很容易乱我的技巧是把每台设备的标签写清楚比如R2-CORE、R3-ISP1“R1-LAN”窗口底色也设置不同一眼就能对上。实验前先把三台路由器的基础配置完成接口IP、loopback、OSPF或者ISIS把二个网段宣告进核心。R1和R2跑OSPFR2和R3之间跑BGP模拟运营商间互联这样能同时体会动态协议里路由策略的用法。注意R2到R3之间起BGP是为了后面实验BGP路由策略比如AS号过滤、cost修改如果你只练PBR那R2和R3之间跑静态路由也行灵活调整。拓扑完成后第一件事不是急着配策略而是先看没有任何策略时流量怎么走。这一步很关键你得先有一个干净的baseline知道默认路径长什么样后面策略下发后才有对比。从R1去往R3方向的服务器默认走哪条路取决于R2的路由表里哪条路由更优。如果R2到ISP1和到专线的两条路由都是直连线路OSPF和BGP在选路时会按协议优先级、cost来定最终大概率是走OSP或BGP学到的某一条。这个默认行为记录下来后面所有实验的对比都以这个为基准。3. 实验一用IP前缀列表和Route-Policy过滤路由先把路由表管起来这个实验的目标很朴素R2从R3通过BGP学到了一批路由我们只允许其中一部分进入R2的路由表或者在学习的同时修改它们的cost和community值。这属于典型的路由策略Routing Policy范畴。3.1 为什么用ip-prefix而不是ACL来匹配路由很多人做路由过滤一上手就写access-list这是个习惯性问题。ACL在设计之初主要是匹配报文用的对路由条目的匹配支持并不是先天优势尤其是在匹配前缀长度精确范围时ACL极其别扭。而IP前缀列表ip ip-prefix天生就是干这个的它支持匹配某前缀匹配掩码长度范围我们看一个例子[R2] ip ip-prefix ALLOW index 10 permit 192.168.10.0 24这条命令的意思是只匹配前缀192.168.10.0、且掩码长度为24位的路由条目。如果想匹配掩码在24到28之间的路由可以写[R2] ip ip-prefix ALLOW index 10 permit 192.168.10.0 24 less-equal 28这里的less-equal 28就限定了掩码长度上限。ACL如果要实现同样的功能你得针对每个掩码长度写一条rule繁琐且容易漏。所以我的建议是路由匹配统一走ip-prefixACL留给PBR或数据流匹配用。3.2 Route-Policy的结构化配置node与if-match的关系配置Route-Policy时华为的语法让我一度很困惑后来想通了就不难了。它的核心结构是节点node匹配条件if-match动作applyroute-policy ONLY-A permit node 10 if-match ip-prefix ALLOW apply cost 100这里有几个点必须说清楚node 10不是优先级数值而是节点的编号用于排序。匹配时从最小的node开始从小到大逐个检查。匹配到node 10且条件是permit就执行apply并结束。permit/deny的作用和ACL不同。在Route-Policy中permit表示允许这条路由通过策略deny表示拒绝这条路由进入下一环节比如不进路由表。但注意如果某个node是deny而且没有匹配到它之前的所有节点那路由会被拒绝。如果在一个node里写了if-match但路由不匹配该条件策略不会直接结束而是跳到下一个node继续判断。这个跳转行为很多人第一次做实验时会忽略导致为什么写了permit node 10之后其他路由也进去了的困惑。我们把实验场景拆开来看。假设R2从R3收到如下路由192.168.10.0/24192.168.20.0/24192.168.30.0/2410.1.0.0/16我们只想让192.168.10.0/24和192.168.20.0/24进路由表其余都拒绝。配置如下[R2] ip ip-prefix LAN10 permit 192.168.10.0 24 [R2] ip ip-prefix LAN20 permit 192.168.20.0 24 [R2] route-policy ONLY-LAN permit node 10 [R2-route-policy] if-match ip-prefix LAN10 [R2-route-policy] route-policy ONLY-LAN permit node 20 [R2-route-policy] if-match ip-prefix LAN20注意这里我写了两个node都是permit。如果路由匹配node 10就通过apply没有写所以不修改属性如果不匹配node 10就跳到node 20再判断如果两个node都没匹配上这条路由会被隐式的deny拒绝。这就是华为策略末尾默认deny all的规则。所以不需要额外写一个deny node。在BGP场景中调用方式是在peer视图下[R2-bgp] peer 10.0.3.3 route-policy ONLY-LAN import这样R2从R310.0.3.3收到的所有路由都会经过该策略。实验时你可以用display bgp routing-table观察过滤前后的路由数量变化用display ip routing-table看最终进路由表的条目。3.3 修改路由属性从过滤到影响选路路由策略的另一个大用途是修改路由属性。比如我希望从R3学到的一条路由cost变成500以便让R1日后选路时不走这条路径但又不希望完全删除它——这时候可以用apply cost。[R2] route-policy SET-COST permit node 10 [R2-route-policy] if-match ip-prefix LAN10 [R2-route-policy] apply cost 500如果是在BGP里还能改local-pref、MED、community等。实验时我建议三件套都试一遍apply cost 500影响IGP选路OSPF里对应改costapply local-preference 200影响BGP选路越大越优默认100apply community 100:200给路由打团体标签为下游设备做二次策略匹配提供依据做完修改动作后在R2上display bgp routing-table 192.168.10.0 24能看到local pref等属性变化这就是策略生效的直接证据。写实验报告时这些前后对比数据非常有说服力。4. 实验二PBR策略路由实战从看路由表到强行改路径这一部分就是热搜词里提到的PBR策略路由。PBR的核心概念我已经在第1部分讲过了现在直接进入实验。沿用上面的拓扑R1下面带着网段A192.168.10.0/24和网段B192.168.20.0/24R2连着两条出口一条走10.0.2.2ISP1方向一条走10.0.3.2专线方向。需求网段A的所有流量走ISP1方向网段B的所有流量走专线方向。用传统路由表实现吗不可能因为传统路由表里查目的地址A和B访问同一个目的地址下一跳必须相同。只有PBR能实现这种基于源地址的选路。4.1 华为的流分类三板斧ACL 流分类 流行为华为设备上做PBR通常用traffic classifier流分类 traffic behavior流行为 traffic policy流策略三位一体。步骤拆开看其实不复杂第一步用ACL识别源网段[R2] acl number 3001 [R2-acl-adv] rule 5 permit ip source 192.168.10.0 0.0.0.255 [R2-acl-adv] acl number 3002 [R2-acl-adv] rule 5 permit ip source 192.168.20.0 0.0.0.255这里用高级ACL匹配源地址0.0.0.255是通配符相当于只关心前三段。第二步定义流分类Classifier[R2] traffic classifier C-A [R2-classifier-C-A] if-match acl 3001 [R2-classifier-C-A] traffic classifier C-B [R2-classifier-C-B] if-match acl 3002第三步定义流行为Behavior——指定下一跳[R2] traffic behavior B-ISP1 [R2-behavior-B-ISP1] redirect ip-nexthop 10.0.2.2 [R2-behavior-B-ISP1] traffic behavior B-MPLS [R2-behavior-B-MPLS] redirect ip-nexthop 10.0.3.2注意这里redirect ip-nexthop的地址必须保证是直连可达的否则PBR无法解析下一跳这也是实验中最容易翻车的地方下一跳写了一个非直连地址策略配置了却不生效。第四步配置流策略Policy并应用到接口[R2] traffic policy PBR-POLICY [R2-policy-PBR-POLICY] classifier C-A behavior B-ISP1 [R2-policy-PBR-POLICY] classifier C-B behavior B-MPLS [R2] interface GigabitEthernet0/0/0 [R2-GigabitEthernet0/0/0] traffic-policy PBR-POLICY inbound关键点来了PBR的应用方向是inbound还是outbound这取决于流量从哪个接口进入设备。我的拓扑中R1的流量从R2的GigabitEthernet0/0/0进入所以在那个接口上应用inbound方向的策略。如果说反了策略永远不会被匹配。这个细节我见过太多人栽过跟头写实验报告时一定要把这个方向搞明白。4.2 思科路由器的PBR对照route-map的简洁风格如果你手边的是思科设备实现同样的需求配置会更简洁interface gigabitethernet0/0 ip policy route-map PBR-POLICY ! access-list 101 permit ip 192.168.10.0 0.0.0.255 any access-list 102 permit ip 192.168.20.0 0.0.0.255 any ! route-map PBR-POLICY permit 10 match ip address 101 set ip next-hop 10.0.2.2 route-map PBR-POLICY permit 20 match ip address 102 set ip next-hop 10.0.3.2思科的route-map逻辑和华为的traffic policy逻辑异曲同工但语法上route-map在一个节点里同时有match和set语义更像如果匹配条件那么就执行动作。思科的策略同样要应用到接口的inbound方向。如果是H3C设备PBR的NQA联动和递归下一跳很出名配置风格又略有不同但核心思路都是匹配特征指定下一跳。4.3 PBR不生效的三个典型原因这个实验我做过十几遍每次都有学生或同事问为什么我配置了策略流还是按原来的路走我很确定问题基本出在这三处下一跳不可达redirect的地址必须是直连路由可解析的设备不支持把流量扔给一个它无法路由到达的下一条。应用方向错误PBR应用在数据流进入设备的那个接口的inbound方向不是出接口方向的outbound。有些人的理解是流量要往ISP走那就应该在去往ISP的那个接口上做这个理解是错的。PBR必须在流量刚进设备、还没查路由表之前做决定。ACL匹配的源方向搞反了在R2接口的inbound方向做PBRACL里的source应该是来自R1的源地址例如192.168.10.0/24而不是目的地址。如果你写成了destination指向某个公网网段大概率匹配不到。还有一个容易被忽略的问题PBR的匹配优先级是顺序匹配先到先得。如果你的ACL 3001写成了一条permit ip any any那后面的3002永远不会被查。所以规则顺序一定要小心。4.4 PBR实验的验证方法别只盯着ping策略下发后怎么验证真的走了指定链路我推荐至少三种手段联合验证第一traceroute路径法。从R1发起traceroute到10.0.2.2或一个远端网段观察路径中R2之后的下一跳是谁。如果网段A的流量经过10.0.2.2而网段B经过10.0.3.2基本能确认PBR生效。但要注意traceroute不一定能直观看到R2之后的第二跳有时只显示第一跳需要在R2上开启icmp超时消息的发送权限。第二display traffic policy statistics。在R2上执行[R2] display traffic policy statistics inbound interface GigabitEthernet0/0/0正常能看到C-A和C-B两个分类的匹配计数在增长。如果某个分类计数一直是0说明ACL没匹配成功。第三接口计数器法。如果两个出接口都有计数功能在R1上大流量ping或打流同时观察R2去往两个出口方向的接口的Input/Output bytes变化。哪个接口的计数器涨得快流量就走哪。这是最无语的物理层验证。5. 实验三PBR结合路由策略的混合场景实现先选路再改路题目叫路由策略实验练习那我把两个内容交叉起来做一个更有代表性的综合实验。需求是这样网段A的流量走ISP1方向并且在ISP1方向学到的某条路由上我们要把它的cost调高使网段A流量到达R3后也不被认为是一条环路或较优路径。这种混合场景在真实组网里很常见既要有PBR按源地址分流又要用Route-Policy影响某个方向上的路由优劣。两个策略是不同层面的PBR在转发平面工作Route-Policy在控制平面路由协议工作。实验步骤可以分两块写块一PBR分流和实验二相同把网段A送去ISP1。块二在R2与R3的BGP邻居上应用route-policy对从R3方向学到的10.0.0.0/22之类的路由打上MED 200或community标记。这样一来即使ISP1方向和专线方向同时学习到10.0.0.0/22R2也会因为MED值不同而选择更低cost的一侧作为回程路径。[R2] route-policy FROM-ISP1 permit node 10 [R2-route-policy] if-match ip-prefix TO-ISP [R2-route-policy] apply med 200 [R2-bgp] peer 10.0.3.3 route-policy FROM-ISP1 import这里的IP前缀列表TO-ISP先定义好要匹配的10.0.0.0/22。综合验证要点在主机侧 ping 服务器观察来回路径的对称性在R2上用display bgp routing-table查看MED对比同时观察R2不同接口的流量计数说实话这个混合场景一出来才算真正把路由策略和策略路由融会贯通了。很多面试题问得天花乱坠其实就是考察你有没有跑通这种左右互搏的脑子。6. 命令之外的辅助工具与调试技巧让实验看得更透实验做得好不好往往不在配置本身而在调试手段。我总结几个必须掌握的调试和排障技巧这是普通教科书里不爱仔细讲的部分。6.1 华为的debug和display组合拳display ip routing-table protocol bgp只看BGP学到的路由快速确认过滤结果。display bgp routing-table statistics看BGP路由总数和过滤情况能直观看到策略生效前后条数差异。debug ip packet华为为debug ip packet思科为debug ip policyPBR场景下打开debug后能看到匹配ACL的报文动作。华为的debug ip packet输出很冗长我建议结合ACL做过滤式debug只关注特定源地址R2 debugging ip packet acl 3001这样只会打印源地址是192.168.10.0/24的报文日志量小很多。display policy-based-route早期版本叫display ip policy-based-route查看PBR配置和匹配次数。这个命令在某些版本上有差异建议先display traffic policy查一下全局配置状态。6.2 抓包用Wireshark实锤转发路径如果你想确认PBR真的把流量转给了某个具体的下一跳更硬的证据是抓包。在EVE-NG的链路两端挂Wireshark或者用Cloud连接真实网卡抓取ICMP报文看源目的IP对不对看MAC地址是否下一跳设备的MAC。我记得有一次调试一个PBR不生效的问题display计数显示匹配了traceroute结果也对不上后来用抓包一看下一跳虽然指对了但出接口因为某种原因又做了一次路由表查询结果绕了一大圈。这类看似生效实则没生效的隐性bug只能靠抓包来确认数据面的真实走向。6.3 用静态路由保底给PBR一个兜底出口在做PBR实验的拓扑里我强烈建议先配置好静态默认路由或OSPF/BGP兜底路由确保在没有启用PBR时环境也能通。然后再下发PBR策略覆盖特定流量。这种先全通再局部改路的渐进式验证思路能极大降低实验排障难度。策略配错了回退也比较简单——移除traffic-policy即可。7. 延伸思考从网络实验到Linux策略路由的相通性如果你把路由策略实验练熟了会发现Linux服务器上的策略路由逻辑和它几乎一模一样只是名字不同。Linux用ip rule定义策略rule用ip route ... table X定义路由表table。比如实现来自10.0.0.0/8的流量走table 10的默认路由ip rule add from 10.0.0.0/8 lookup 10 ip route add default via 10.1.1.1 dev eth1 table 10这条rule和华为的traffic classifier C-A if-match acl 3001本质上是同一个思路先匹配流量特征再指定转发规则。我建议学习者在做完网络设备实验后找一台Linux虚机把同样需求实现一遍。跨平台之后你会发现所有策略类技术的底层思维是一致的分类classification 动作action 应用位置application point。把握住这个三角任何厂商的文档都能举一反三。8. 实验报告怎么写让一张拓扑讲清三类结论最后聊一个容易被忽视的问题——实验记录。很多人实验做完截图一截就完事了但真正有价值的实验报告应该把为什么写清楚。我的习惯是每个实验记录三件事策略配置前后的路由表/bgp表对比把display结果贴出来标注出变化条目这是证据链。一项原始需求对应一条配置逻辑比如让A网段走ISP1对应的就是ACL 3001里source是A网段、behavior把nexthop指向10.0.2.2。这样事后回看每个配置都有据可查。验证方法及结果截图至少包含display policy统计、traceroute路径、接口计数三张图。数字对比是实验报告的灵魂没有验证的实验等于白做。另外每次实验结束时我都会把配置清理干净重新回到baseline状态再开始下一个实验。保持每次实验的单变量原则——只改动一个策略因素其他都不变——这样得到的结论才可信。这套路由策略实验练习的完整流程走下来你基本就拥有了独立设计、调优和排障的能力。别再对着厂商白皮书死记硬背了拓扑搭起来命令敲下去你才能真正理解策略的路由世界是什么样。