企业官网建设流程全解析

最近正好在整理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-policy，LSA仍然会泛洪到整个区域，只是邻居在计算路由时是否会使用这些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和R3，R2底下有办公网段192.168.0.0/16，R3底下有生产网段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-Prefix，ACL留给报文过滤和数据面控制去用，不要把两种工具混在一个策略里，可读性和排错逻辑都会清晰很多。

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 问题速查表与根因分析

这里整理了我实际调试中遇到的高频问题场景，每一个都对应真实的排障经验。

5.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-table，BGP执行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那样大篇幅出现，但在路由策略综合题里，它往往是拿分的关键。把原理吃透、把实验做扎实，比背多少道题目都管用。