最近正好在整理HCIP的备考笔记翻到路由策略这一章时我觉得filter-policy这个知识点非常值得单独拿出来聊聊。它属于路由控制类工具名字听起来简单但在实际网络运维中无论是OSPF、IS-IS还是BGP环境出镜率都极高。用一句话概括它的用处filter-policy通过调用ACL或地址前缀列表控制路由的接收、发布和通告是调整路由表最简单直接的手段。这篇文章主要面向正在备考HCIP的工程师也适合日常需要做路由隔离、路由优化的一线运维人员。我会从工具定位、工作原理、配置实操到排障技巧把这些年积累的经验和踩过的坑一次讲清楚。如果你正准备做路由策略相关的实验或者在实际项目里被路由过滤问题卡住这篇内容应该能帮你省下不少时间。1. 路由策略的全局观filter-policy在路由控制体系中坐哪把交椅1.1 三类路由控制工具的分工逻辑刚开始学路由策略时很多人容易把filter-policy、route-policy和策略路由弄混。这三个工具名字里都带策略但干的活完全不同。我用一个生活化的类比来解释把路由器比作小区门口路由表就是业主名单。filter-policy是门卫只负责一件事——凭单子放行或拦截路由条目。它不修改路由的任何属性只看这个路由能不能进或能不能出。route-policy是物业经理不仅能决定放行还是拦截还能给路由改身份比如修改MED、Local-Pref、Community等属性是精细化控制的担当。策略路由PBR则是导航员它不关心路由表怎么生成而是直接影响报文转发路径让流量走指定出口。理解了这三者的位置就明白为什么filter-policy常常是首选——它轻量、简单、易排错。在只需要过滤而不需要修改属性的场景下用filter-policy就够了。一旦需要改属性比如修改BGP的团体属性做流量调度就得请出route-policy。这个选择逻辑是项目方案设计的基础。1.2 filter-policy在路由学习全流程中的插入点动态路由协议工作时分三个阶段接收邻居报文、计算路由、加载到路由表。filter-policy的插入点非常关键它作用在路由表生成之前或之后而不是在协议报文收发层。具体来说协议报文照常接收邻居关系照常建立LSA或路由条目照样进数据库但filter-policy决定这些路由能不能进入路由表。这也是新手最容易困惑的地方我明明在OSPF里配置了filter-policy为什么display ospf lsdb还能看到那条LSA因为filter-policy管的是路由表这一个层面管不到链路状态数据库。这个特点既是优点也是陷阱理解了它排障时就不会跑去检查协议报文白白浪费时间。2. filter-policy工作机制拆解三个方向、两个层面2.1 三大控制方向入方向、出方向与本地通告filter-policy在不同协议里支持的过滤方向不太一样但总体可以归为三类。我在实验环境里分别验证过这里把核心逻辑整理出来。第一类是入方向过滤inbound。它过滤的是从邻居收到的路由只有通过匹配的路由才会被写进本机路由表。注意这里的收到的路由在不同协议里含义不同在BGP里入方向过滤影响的是从对等体收到的BGP路由在OSPF里入方向过滤影响的是SPF计算后生成的路由。实际项目里入方向过滤常用于我只想接收某些网段的路由其他都不要比如总部和分支互联时分支只希望收到总部的核心网段。第二类是出方向过滤outbound。它过滤的是本地向邻居发布的路由。在BGP场景中出方向过滤配合邻居或对等体组使用控制本地向对端通告哪些路由这是BGP网络中做路由管控的最常见手段之一。在OSPF中出方向过滤主要在ASBR上控制Type3、Type5路由的发布。第三类是本地通告过滤概念上可以看作是出方向的一种特殊形式但在具体实现上它控制的是本地协议路由的对外通告比如在OSPF的ABR上控制某个区域间的路由通告。从使用频率和配置复杂性来看BGP的filter-policy最灵活OSPF的相对受限但也能实现有效控制。入方向和出方向的选择取决于你站在哪个节点、要控制哪个方向的路由流向这是设计路由策略时首先要回答的问题。2.2 OSPF与BGP场景下的行为差异OSPF场景下的filter-policy有约定俗成的说法只能过滤路由不能过滤LSA。这意味着即使你在ABR或ASBR上配置了出方向的filter-policyLSA仍然会泛洪到整个区域只是邻居在计算路由时是否会使用这些LSA形成路由表项会受到本地入方向过滤的影响。严格来说OSPF的filter-policy是控制路由表生成而非控制协议报文传播。所以如果项目目标是真正减少OSPF区域内LSA泛洪正确的手段应该是区域划分、路由汇总、Stub/Totally Stub区域和NSSA区域而不是filter-policy。BGP场景下的filter-policy行为则更实在一些。BGP本身就是基于距离矢量的路径向量协议路由是通过Update报文传递的。入方向过滤会直接影响接收的Update报文处理出方向过滤会控制发给邻居的路由。配置得当的话邻居那边display bgp routing-table就会真的看不到被过滤的路由。这里有个经验BGP使用peer x.x.x.x filter-policy结合地址前缀列表这是华为设备上常见的BGP路由控制方式。在组网设计时要留意出方向过滤是在本端控制发什么入方向过滤是在本端控制收什么两端的过滤策略可以独立配置互不影响。2.3 与ACL、地址前缀列表的配合关系filter-policy本身只是一个框架命令真正干活的是被它调用的匹配工具。常用的有两个ACL访问控制列表和地址前缀列表IP-Prefix。理解二者的差异直接决定了你的策略写出来是精确还是粗糙。ACL匹配路由时核心是匹配网络号用反掩码通配符来确定匹配范围。比如acl number 2000配合rule 5 permit source 10.1.0.0 0.0.255.255匹配的是所有以10.1开头的网络号。但ACL有一个明显短板它不关心掩码长度。这意味着10.1.0.0/16和10.1.0.0/24在ACL眼里都可能被匹配。对于路由过滤这种对掩码敏感的场景ACL显然不够精确。地址前缀列表IP-Prefix专门为路由匹配而生它可以精确匹配网络号和掩码长度。比如ip ip-prefix TEST index 10 permit 10.1.0.0 16 greater-equal 24 less-equal 28的意思是匹配10.1.0.0/16内的路由且掩码长度必须在24到28位之间。这种精度是ACL做不到的。所以我的建议是凡是filter-policy一律优先使用IP-Prefix除非你就是要做粗粒度的过滤。这个习惯能显著减少日后策略调整带来的排错成本。3. 实操配置从基础到进阶的完整演示3.1 基础三件套前缀列表定义与调用无论项目大小配置filter-policy基本都遵循三步走。第一步定义匹配工具通常用ip ip-prefix或acl。第二步在协议视图下调用filter-policy指定方向并绑定匹配工具。第三步验证策略是否生效用display命令对比路由表变化。以下是一段最基础的配置示例。假设我们要在R1上过滤来自对端的路由只允许10.10.0.0/16内的路由进入本机路由表。# 第一步定义地址前缀列表只匹配10.10.0.0/16且掩码长度为24位的路由 ip ip-prefix FROM-R2 index 10 permit 10.10.0.0 16 greater-equal 24 less-equal 24 # 第二步在OSPF视图下调用入方向过滤 ospf 1 filter-policy ip-prefix FROM-R2 import # 第三步验证 display ospf routing-table display ip routing-table这段配置的效果是R1仍然和R2保持OSPF邻居关系LSA照常交互但最终R1的路由表中只会出现掩码为24位且在10.10.0.0/16范围内的OSPF路由。其他路由一律进不了路由表。3.2 场景一OSPF场景下隔离生产网段与办公网段实际项目里经常遇到一个区域同时承载生产业务和办公业务但某些节点不想让办公网段的路由进入核心路由表的情况。比如R1位于核心层同时连接着两个汇聚设备R2和R3R2底下有办公网段192.168.0.0/16R3底下有生产网段10.1.0.0/16。在R1上我们希望生产网段完全可见办公网段全部不可见。在R1上可以这样配置# 定义前缀列表仅允许10.1.0.0/16内的路由 ip ip-prefix PROD index 10 permit 10.1.0.0 16 greater-equal 24 less-equal 24 # 在OSPF视图下做入方向过滤 ospf 1 filter-policy ip-prefix PROD import配置完成后R1的路由表只会保留10.1.x.0/24的生产路由192.168.x.0/24不会被写入路由表。但R1仍然可以和R2、R3正常建立OSPF邻居关系区域内的LSDB也完整无缺。这种方案的优点是改动小不需要调整OSPF区域划分缺点是R1上其实还有这些LSA只是不生成路由。对于恰当隐藏路由、避免路由表膨胀这个目标这种方案是可行的。需要提醒的是在OSPF中如果把filter-policy配置在出方向且用在ABR上要特别留意它对Type3 LSA的影响。华为设备上OSPF的filter-policy出方向可以结合acl或前缀列表在ABR上起到类似路由过滤Type3过滤的效果但在ASBR上只影响Type5路由的生成不会阻止Type5 LSA的泛洪。这个细节在HCIP考试和实际排障中都容易出题值得背下来。3.3 场景二BGP邻居间出方向路由管控BGP场景是filter-policy最有价值的应用地。典型需求是本地作为AS 65001的出口路由器只向某个专线客户发布默认路由和两个业务网段其他路由一律不发。这在多线接入场景下非常常见。配置如下# 定义地址前缀列表只允许默认路由和两个业务网段 ip ip-prefix TO-CUSTOMER index 5 permit 0.0.0.0 0 ip ip-prefix TO-CUSTOMER index 10 permit 172.16.1.0 24 ip ip-prefix TO-CUSTOMER index 20 permit 172.16.2.0 24 # 在BGP视图中对指定邻居调用出方向过滤 bgp 65001 peer 192.168.20.1 as-number 65002 peer 192.168.20.1 filter-policy ip-prefix TO-CUSTOMER export配置完成后在R1上执行display bgp routing-table peer 192.168.20.1 advertised-routes你只会看到默认路由0.0.0.0/0和172.16.1.0/24、172.16.2.0/24三条。客户侧设备上的BGP表也是同样干净。这种做法的好处是不需要修改路由属性不需要建route-policy控制粒度完全够用。值得注意的是BGP里出方向过滤有一种替代方案是peer x.x.x.x route-policy但filter-policy的配置量更小、可读性也更强。考试和面试时能清楚说出何时用filter-policy、何时用route-policy本身就是区分经验深浅的一个点。4. 高级用法与关键参数细节4.1 ip-prefix的掩码匹配参数mask-length、greater-equal与less-equal地址前缀列表是filter-policy最得力的搭档但很多人对它的参数理解不到位。这里我展开讲清楚因为一旦写错路由匹配结果会和预期天差地别。ip ip-prefix NAME index NUM permit A.B.C.D [mask-length] [greater-equal N] [less-equal M]的基本逻辑是先匹配网络号再匹配掩码长度范围。如果只写10.1.1.0 24表示精确匹配10.1.1.0/24。如果写10.1.0.0 16 greater-equal 20 less-equal 28表示匹配网络号落在10.1.0.0/16内、掩码长度在20到28位之间的所有路由。如果写了10.1.0.0 16 greater-equal 20而不写less-equal表示掩码大于等于20的所有路由都匹配。如果写了10.1.0.0 16 less-equal 28而不写greater-equal表示掩码从17位到28位之间的路由匹配。很多实验里大家喜欢写10.1.0.0 16但忘记带上掩码范围结果导致所有掩码长度的10.1.x.x路由都被放行。所以我在实际环境里基本都会明确写出greater-equal和less-equal哪怕是精确匹配也会写成greater-equal 24 less-equal 24这样做的好处是策略意图一目了然后续维护者不会产生歧义。另外地址前缀列表的匹配原则是按index序号从小到大逐条匹配匹配即停止。所以index 10若没有匹配继续看index 20如果所有条目都不匹配路由默认被拒绝隐含拒绝所有。这是前缀列表和ACL最大的区别之一ACL末尾也是隐式拒绝但前缀列表的每条规则之间是或的关系写多条时顺序影响结果。在很多项目事故里就是因为把精确路由写在宽泛路由之后导致精确路由永远匹配不到。4.2 gateway参数按下一跳过滤的特殊用法在BGP或OSPF场景中有时需要按路由的下一跳来过滤而不是按目的网段。比如我们只希望接收来自某个特定对端设备的路由任何从其他设备教育过来的BGP路由都不收。这时候可以借助前缀列表中的gateway选项。# 只允许下一跳为192.168.100.1的路由 ip ip-prefix NH-CHECK index 10 permit 0.0.0.0 0 less-equal 32 ip ip-prefix NH-CHECK index 20 permit 0.0.0.0 0 greater-equal 0 less-equal 32 gateway 192.168.100.1实际使用中gateway参数要求匹配的下一跳地址必须在if-match指定的范围内。华为设备中这个参数在OSPF的filter-policy和BGP中都可以配合使用是处理复杂组网时的利器。需要注意的是这个参数不是所有场景都生效比如OSPF的区域内路由下一跳可能是多跳之外的地址不一定是直连邻居这时gateway匹配要结合实际下一跳情况来写。4.3 ACL作为匹配工具时的反掩码细节虽然我建议优先使用前缀列表但有些旧环境里仍然使用ACL需要掌握ACL匹配路由时容易踩的坑。ACL用于filter-policy时匹配的是路由的目的网络号其中0表示必须精确匹配255表示不关心。比如permit ip 10.1.1.0 0.0.0.255会匹配10.1.1.0/24网段的任何掩码长度的路由。原因上面说过了ACL根本不检查掩码长度。所以在写ACL做路由过滤时千万别以为10.1.1.0 0.0.0.255只匹配/24它会把10.1.1.0/25、10.1.1.0/32等网络号在10.1.1.x范围内的所有路由都匹配上。另外ACL的规则顺序同样重要默认从上往下匹配匹配即停止。很多ACL里写着rule 5 deny加rule 10 permit顺序反了结果就完全不同。我的建议是在新建工程里路由过滤尽量用IP-PrefixACL留给报文过滤和数据面控制去用不要把两种工具混在一个策略里可读性和排错逻辑都会清晰很多。4.4 filter-policy与route-policy的选择边界很多同学喜欢遇到路由控制就直接上route-policy总觉得它功能强大、一步到位。但从工程角度过度设计同样有成本。filter-policy在纯过滤场景下更直观、排错简单而route-policy在需要修改属性或者组合多个匹配条件时才是正确的选择。举个例子如果需求是拒绝接收10.1.0.0/16路由并允许其他所有路由用filter-policy很简单ip ip-prefix DENY-10 index 10 deny 10.1.0.0 16 ip ip-prefix DENY-10 index 20 permit 0.0.0.0 0 less-equal 32 ospf 1 filter-policy ip-prefix DENY-10 import如果需求升级为拒绝接收10.1.0.0/16路由并对于其他路由打上特定Community属性那就必须用route-policy了。因为filter-policy做不了属性修改。这个边界搞清楚了方案设计时就不会纠结。5. 常见问题与排查技巧实录5.1 问题速查表与根因分析这里整理了我实际调试中遇到的高频问题场景每一个都对应真实的排障经验。现象可能原因排查思路OSPF配置filter-policy后LSDB中仍有被过滤的路由误认为filter-policy可以过滤LSA泛洪检查LSDB理解filter-policy只影响路由表生成不影响数据库同步前缀列表写了很多条目但过滤结果不对index顺序错误导致宽泛条目优先匹配用display ip ip-prefix查看所有条目核对顺序和索引号BGP邻居出方向策略不生效调用了错误方向或在错误对等体下配置检查display bgp peer的使能状态和策略方向用advertised-routes验证OSPF入方向过滤后出现环路风险只是本地不接收路由别的设备仍可能转发结合拓扑分析确认是否需要全局范围内做过滤而不是某台设备单独过滤filter-policy export方向不支持ACL某些协议方向对ACL类型有限制换用IP-Prefix作为匹配工具路由一直在路由表内新策略不生效没有重置协议进程或BGP会话OSPF执行reset ospf processBGP执行refresh bgp或reset bgp5.2 排障过程中的三层检查法实际排查filter-policy问题时我一般按照查匹配→查调用→查现象三层顺序来走。第一层查匹配。先在设备上执行display ip ip-prefix核对前缀列表的内容、顺序、索引是否与设计一致。这一步能发现大多数 为什么我没过滤住 的问题。对于ACL使用display acl all查看规则数和匹配统计如果计数不增长说明报文根本没走到这条规则。第二层查调用。确认filter-policy是否在正确的协议视图下、正确的方向下被调用。比如OSPF里忘了输入import策略就不会生效。BGP里调用少了某个邻居策略就只对部分对等体生效。这一步简单的display current-configuration configuration ospf或display current-configuration configuration bgp就能搞定。第三层查现象。OSPF执行display ospf routing-table和display ip routing-tableBGP执行display bgp routing-table以及display bgp routing-table peer X.X.X.X advertised-routes对照期望结果一列列比对。如果现象和预期不一致基本可以定位到匹配或调用环节的疏漏。这套检查法在项目交付和考试实验里都非常实用。忘了在哪一层卡住多数是因为省略了第一层直接看路由表结果被路由表符合预期蒙蔽了判断力。5.3 配置改动后的生效时机filter-policy配置完成后不是磨盘一转就生效的不同协议的生效时机有差异这个细节经常让新人误判为配置没生效。在OSPF里新建或修改filter-policy后需要执行reset ospf process才会触发路由重新计算否则新策略不会立刻应用到已有路由。在BGP里入方向filter-policy可以通过refresh bgp all软重置接收路由出方向可以通过refresh bgp all export触发Update报文发送。在IS-IS里变更策略后需要reset isis all或reset isis peer来重新计算路由。我在做变更时习惯先说清楚改了什么、预计什么时候生效、如何验证再动手改配置。比如OSPF场景改完filter-policy后不等自动收敛直接手动重置OSPF进程然后观察路由表的更新。需要注意的是reset ospf process会中断该进程下的所有OSPF邻居关系属于影响性操作在业务高峰期要格外谨慎。6. 实操心得几个让策略更稳的设计习惯关于路由策略的项目经验我最后分享几个个人长期坚持的设计习惯。首先每个prefix-list都必须写明index按5、10、15这样留空位方便以后插条目而不需要重排。其次每条策略都要有明确的命名规范比如FROM-BACKUP、TO-CUSTOMER而不是aa、bb这种无意义缩写。第三在配置里加上注释比如# 只放行生产网段办公网段全部拒绝这对后续交接和维护非常有价值。我的一个深刻体会是filter-policy是最容易配置起来很顺手、排错时很痛苦的命令。顺手是因为它语法简单痛苦是因为一旦涉及多个节点、多个方向想搞清楚一条路由为什么消失、为什么还在就要花不少时间梳理。这时候规范化的配置习惯能救命。我在某次项目割接中就因为一条前缀列表的index顺序写反导致核心设备上的业务路由无法正常接收流量中断了十几分钟。事后复盘根因就是我图省事没检查index顺序宽泛条目在前精确条目永远匹配不到。所以每次配置完filter-policy我都会强迫自己做一次三查查前缀列表内容、查调用方向、查路由表结果。虽然多花两分钟但能省下后面几小时的排障时间。这个习惯我相信新手如果能坚持下来技术水平会提升得很快。HCIP考试中filter-policy不像BGP那样大篇幅出现但在路由策略综合题里它往往是拿分的关键。把原理吃透、把实验做扎实比背多少道题目都管用。