1. 前缀列表到底解决了什么问题
第一次接触前缀列表是在一个园区网改造项目里，当时需要在一台核心设备上做路由过滤，要求很明确：只允许特定的几条业务网段通过，其余全部拒绝。我一开始用的是基础ACL，写完发现根本没法精确匹配掩码长度——比如我想只放行 10.1.0.0/16，但ACL的规则会把 10.1.1.0/24 这种更具体的子网也一并放过去。这个问题困扰了我好一阵，直到翻文档才意识到，前缀列表（ip ip-prefix）才是干这个事的正确工具。
前缀列表本质上是一个路由匹配工具，它和ACL最大的区别在于：ACL匹配的是数据包的源目地址，而前缀列表匹配的是路由条目本身，而且能同时匹配网络地址和掩码长度。这个能力在路由策略场景里非常关键。你可以把它理解成一个带掩码校验的筛子——不光看网段对不对，还要看掩码长度是否符合预期。
它主要用在几个地方：路由引入时的过滤、BGP邻居的路由收发策略、OSPF/IS-IS区域间的路由过滤等。适合谁学？我觉得只要你在做网络运维、路由交换配置，或者准备考华为认证（HCIP/HCIE方向），前缀列表都是绕不过去的基本功。它不像某些高级特性那样只在特定场景才用得上，而是日常配置里高频出现的工具。
这篇文章我会从原理讲到实验，把匹配规则、配置命令、常见坑点都拆开说清楚。所有实验基于华为VRP系统，用eNSP模拟器就能完整复现。我尽量把每个参数为什么这么设、不这么设会出什么问题都讲透，让你看完能直接上手配。
2. 前缀列表的核心原理拆解
2.1 和ACL的本质区别在哪
很多人刚学的时候会把前缀列表和ACL混为一谈，觉得都是过滤工具，随便用哪个都行。实际上两者的匹配维度完全不同。ACL匹配的是"地址范围"，比如 10.1.1.0 0.0.0.255 匹配的是 10.1.1.0/24 这个网段里的所有地址。而前缀列表匹配的是"路由前缀"，格式是 网络地址 + 掩码长度。
举个例子你就明白了。假设有一条路由 10.1.1.0/24，你用ACL规则rule permit source 10.1.0.0 0.0.255.255，这条路由是能匹配上的。但如果你只想匹配掩码长度恰好是24位的路由，ACL就无能为力了——它没法表达"掩码必须是24"这个条件。前缀列表可以，写成ip ip-prefix test permit 10.1.0.0 16 less-equal 24，这样就能精确控制掩码范围。
这个区别在实际项目里影响很大。比如做BGP路由汇总的时候，你只想接收汇总路由而不接收明细路由，用ACL根本做不到，必须用前缀列表配合掩码长度范围来精确匹配。
2.2 匹配规则的五种写法
前缀列表的匹配规则看起来简单，但里面的门道不少。核心语法是：
ip ip-prefix <名称> [index <序号>] permit|deny <网络地址> <掩码长度> [匹配模式]掩码长度后面可以跟几种匹配模式，这是最容易搞混的地方。我把它整理成表格，方便对照：
| 匹配模式 | 含义 | 示例 | 匹配结果 |
|---|---|---|---|
| 不写 | 精确匹配掩码长度 | permit 10.1.0.0 24 | 只匹配 10.1.0.0/24 |
| greater-equal X | 掩码长度大于等于X | permit 10.1.0.0 16 greater-equal 24 | 匹配 10.1.0.0/24 到 /32 |
| less-equal X | 掩码长度小于等于X | permit 10.1.0.0 16 less-equal 24 | 匹配 10.1.0.0/16 到 /24 |
| greater-equal X less-equal Y | 掩码长度在X到Y之间 | permit 10.1.0.0 16 greater-equal 20 less-equal 24 | 匹配 /20 到 /24 |
| 只写网络地址不写掩码 | 匹配所有掩码 | permit 10.1.0.0 | 匹配 10.1.0.0 开头的所有路由 |
这里有个关键点：当你不写掩码长度、只写网络地址的时候，它匹配的是"网络地址部分相同"的所有路由，掩码长度不限。这个用法在需要放行某个大网段下所有子网时很方便，但也很容易误放行不该放的路由，用的时候要小心。
还有一个细节：greater-equal 和 less-equal 后面的数字必须大于等于前面写的掩码长度。比如你写permit 10.1.0.0 24 greater-equal 16，这是非法的，因为16小于24。设备会直接报错。这个规则背后的逻辑是：前缀列表匹配的前提是网络地址部分要先匹配上，掩码长度范围是在这个基础上做进一步筛选。
2.3 序号和匹配顺序的坑
前缀列表和ACL一样，是按序号从小到大依次匹配的，一旦匹配上就停止，不再往下查。默认情况下，如果你不写index，设备会自动分配序号，步长是10。比如你连续写三条规则，序号就是10、20、30。
这里有个很多人踩过的坑：前缀列表末尾有一个隐式的deny。也就是说，如果你写的规则没有匹配上某条路由，默认行为是拒绝。这和ACL的隐式拒绝是一样的逻辑。但问题是，很多人写前缀列表的时候只写了permit规则，忘了考虑没匹配上的路由会被拒绝，结果导致一些本该放行的路由被过滤掉了。
我的习惯是：在写permit规则之前，先想清楚"哪些要放行、哪些要拒绝"，如果需求是"只拒绝少数几条、其余全放行"，那就要在末尾显式加一条permit 0.0.0.0 0 less-equal 32来放行所有路由。这条规则的意思是匹配所有网络地址、掩码长度从0到32的路由，相当于放行一切。
序号还有一个作用：方便后续插入或删除规则。如果你一开始用默认序号10、20、30，后来想在中间插一条，就得重新规划序号。我的建议是初始就留出间隔，比如用10、20、30这样，中间留空位方便插入。如果要更灵活，可以手动指定序号，比如10、15、20，这样中间还能插12、13。
2.4 匹配过程到底怎么走的
理解匹配过程对排查问题特别重要。当一条路由过来的时候，前缀列表的匹配逻辑是这样的：
第一步，取出路由的网络地址部分，和规则里的网络地址做比对。注意这里比对的是网络地址，不是掩码。比如规则写的是 10.1.0.0 16，那路由的网络地址前16位必须和 10.1.0.0 的前16位一致。
第二步，如果网络地址匹配上了，再看掩码长度是否在规则指定的范围内。如果规则没写掩码范围，就精确匹配规则里写的掩码长度。
第三步，如果网络地址和掩码长度都匹配，就执行这条规则的动作（permit或deny），匹配过程结束。如果没匹配上，继续查下一条规则。
第四步，如果所有规则都没匹配上，执行隐式deny，路由被拒绝。
这个流程看起来简单，但实际排查问题的时候，经常是网络地址匹配上了、掩码长度没匹配上，导致路由被意外拒绝。比如你写permit 10.1.0.0 16，结果来了一条 10.1.0.0/24 的路由，网络地址部分是一样的，但掩码长度是24不是16，所以匹配不上，继续往下查。如果后面没有能匹配的规则，这条路由就被拒绝了。
3. 华为设备上的配置实操
3.1 基础配置命令逐条拆解
先看最基本的配置。假设我们要创建一个名为test-prefix的前缀列表，只允许 192.168.1.0/24 这条路由通过：
ip ip-prefix test-prefix index 10 permit 192.168.1.0 24这条命令拆开看：ip ip-prefix是固定开头，test-prefix是列表名称（自己起，建议见名知意），index 10是序号（可省略，省略时自动分配），permit是动作，192.168.1.0 24是匹配条件。
如果要放行一个网段下的所有子网，比如 192.168.0.0/16 下面的所有路由：
ip ip-prefix test-prefix index 10 permit 192.168.0.0 16 less-equal 32这里less-equal 32表示掩码长度从16到32都匹配。为什么是32？因为IPv4最大掩码长度就是32。这条规则会匹配 192.168.0.0/16、192.168.1.0/24、192.168.1.1/32 等等。
如果要匹配掩码长度在某个区间内的路由，比如只要 /20 到 /24 的：
ip ip-prefix test-prefix index 10 permit 192.168.0.0 16 greater-equal 20 less-equal 24注意这里 greater-equal 后面的20必须大于等于前面写的16，否则报错。
3.2 在路由策略里调用前缀列表
前缀列表本身只是一个匹配工具，要真正生效，得在路由策略（route-policy）或者过滤策略（filter-policy）里调用。最常见的用法是在BGP里做路由过滤。
假设我们要在BGP邻居上做入方向过滤，只接收 10.1.0.0/16 到 /24 的路由：
ip ip-prefix bgp-in index 10 permit 10.1.0.0 16 less-equal 24 ip ip-prefix bgp-in index 20 deny 0.0.0.0 0 less-equal 32 route-policy bgp-filter permit node 10 if-match ip-prefix bgp-in bgp 100 peer 10.0.0.2 as-number 200 peer 10.0.0.2 ip-prefix bgp-in import这里有几个点要注意。第一，前缀列表里我加了一条显式的deny规则，序号20，匹配所有路由。为什么要加这条？因为如果不加，末尾的隐式deny也会拒绝所有没匹配上的路由，效果是一样的。但显式写出来更清晰，方便后续维护的时候一眼看出意图。
第二，route-policy 里的 if-match 调用前缀列表，node 10 的动作是 permit。如果前缀列表匹配上了，route-policy 就放行；如果没匹配上，route-policy 继续查下一个node，如果没有下一个node，默认是deny。
第三，BGP邻居上直接用ip-prefix import也可以，不一定要走route-policy。但route-policy更灵活，可以在匹配前缀列表的同时还匹配其他条件（比如AS路径、团体属性等）。
3.3 在OSPF里做路由过滤
OSPF里用前缀列表做过滤，通常是在ABR或者ASBR上。比如在ABR上过滤区域间的路由：
ip ip-prefix ospf-filter index 10 deny 172.16.0.0 16 less-equal 32 ip ip-prefix ospf-filter index 20 permit 0.0.0.0 0 less-equal 32 ospf 1 area 0 filter ip-prefix ospf-filter import这里我用了"先拒绝、后放行"的写法。第一条规则拒绝 172.16.0.0/16 及其所有子网，第二条规则放行其余所有路由。这种写法在需要"排除少数、放行多数"的场景里很常见。
注意OSPF的filter命令是在area视图下配置的，import方向表示过滤进入这个区域的路由，export方向表示过滤从这个区域发布出去的路由。具体用哪个方向，取决于你的需求。
3.4 配置检查与验证命令
配完之后怎么确认生效了？几个常用命令：
display ip ip-prefix test-prefix这条命令查看前缀列表的内容，包括序号、匹配条件、已匹配的计数。计数这个信息很有用，如果某条规则的计数一直是0，说明没有路由匹配上，可能是规则写错了。
display route-policy bgp-filter查看路由策略的配置和匹配计数。
display bgp routing-table peer 10.0.0.2 received-routes查看从BGP邻居接收到的路由，确认过滤是否生效。
display ospf routing查看OSPF路由表，确认过滤后的路由情况。
我习惯在配完之后用display ip ip-prefix看一眼计数，如果计数不对，再回头检查规则。这个习惯帮我省了很多排查时间。
4. 完整实验过程记录
4.1 实验拓扑与目标
实验拓扑很简单：两台路由器直连，R1和R2之间跑BGP。R1上配置若干条静态路由，通过BGP发布给R2。R2上用前缀列表做入方向过滤，只接收特定的路由。
具体目标：R1发布 10.1.0.0/16、10.1.1.0/24、10.1.1.1/32、10.2.0.0/16、10.2.1.0/24 这五条路由。R2只接收 10.1.0.0/16 到 /24 范围内的路由，10.2.0.0/16 及其子网全部拒绝。
拓扑用eNSP搭建，R1和R2用GE0/0/0直连，网段 192.168.12.0/24。R1的接口地址 192.168.12.1，R2的接口地址 192.168.12.2。
4.2 R1的配置
先配接口和BGP：
sysname R1 interface GigabitEthernet0/0/0 ip address 192.168.12.1 255.255.255.0 bgp 100 peer 192.168.12.2 as-number 200 ipv4-family unicast peer 192.168.12.2 enable network 10.1.0.0 255.255.0.0 network 10.1.1.0 255.255.255.0 network 10.1.1.1 255.255.255.255 network 10.2.0.0 255.255.0.0 network 10.2.1.0 255.255.255.0这里有个细节：BGP用network命令发布路由的时候，对应的路由必须在IP路由表里存在。所以我需要先在R1上配静态路由指向这些网段。为了简化，我用黑洞路由：
ip route-static 10.1.0.0 255.255.0.0 NULL0 ip route-static 10.1.1.0 255.255.255.0 NULL0 ip route-static 10.1.1.1 255.255.255.255 NULL0 ip route-static 10.2.0.0 255.255.0.0 NULL0 ip route-static 10.2.1.0 255.255.255.0 NULL0配完之后用display bgp routing-table确认五条路由都发布出去了。
4.3 R2的过滤配置
R2上先配接口和BGP邻居：
sysname R2 interface GigabitEthernet0/0/0 ip address 192.168.12.2 255.255.255.0 bgp 200 peer 192.168.12.1 as-number 100 ipv4-family unicast peer 192.168.12.1 enable然后配前缀列表和路由策略：
ip ip-prefix bgp-in index 10 permit 10.1.0.0 16 less-equal 24 ip ip-prefix bgp-in index 20 deny 0.0.0.0 0 less-equal 32 route-policy bgp-filter permit node 10 if-match ip-prefix bgp-in bgp 200 ipv4-family unicast peer 192.168.12.1 route-policy bgp-filter import这里我用了route-policy来调用前缀列表。也可以直接用peer 192.168.12.1 ip-prefix bgp-in import，效果一样。用route-policy的好处是后续如果要加其他匹配条件，直接在这个策略里加就行。
4.4 验证过滤效果
配完之后，在R2上查看BGP路由表：
display bgp routing-table预期结果是：10.1.0.0/16、10.1.1.0/24、10.1.1.1/32 这三条路由应该被接收，10.2.0.0/16 和 10.2.1.0/24 应该被拒绝。
实际验证下来，结果符合预期。10.1.0.0/16 的掩码长度是16，在16到24范围内，匹配第一条规则，放行。10.1.1.0/24 的掩码长度是24，也在范围内，放行。10.1.1.1/32 的掩码长度是32，不在16到24范围内，第一条规则匹配不上，继续查第二条规则，第二条规则匹配所有路由，动作是deny，所以被拒绝。
等等，这里有个问题。我原本的意图是只接收 10.1.0.0/16 到 /24 的路由，10.1.1.1/32 应该被拒绝。但实际结果是它被拒绝了，这符合预期。但如果你希望 /32 的主机路由也被接收，就需要把 less-equal 改成 32。
再看 10.2.0.0/16，网络地址是 10.2.0.0，第一条规则匹配的是 10.1.0.0，网络地址不匹配，继续查第二条规则，被拒绝。10.2.1.0/24 同理，被拒绝。
用display ip ip-prefix bgp-in查看匹配计数，可以看到第一条规则匹配了3次（10.1.0.0/16、10.1.1.0/24、10.1.1.1/32 都匹配了第一条规则，但 10.1.1.1/32 因为掩码长度不在范围内，实际上没有匹配上第一条规则，而是匹配了第二条规则被拒绝）。这里计数显示的是匹配次数，不是放行次数，要注意区分。
4.5 调整规则验证不同效果
为了验证 greater-equal 和 less-equal 的组合效果，我改了一下规则：
ip ip-prefix bgp-in index 10 permit 10.1.0.0 16 greater-equal 24 less-equal 32这样改完之后，10.1.0.0/16 的掩码长度是16，不在24到32范围内，匹配不上第一条规则，被第二条规则拒绝。10.1.1.0/24 的掩码长度是24，在范围内，放行。10.1.1.1/32 的掩码长度是32，在范围内，放行。
这个实验说明了一个重要点：前缀列表的掩码长度范围是精确控制的，greater-equal 和 less-equal 的边界值都包含在内。写规则的时候一定要想清楚边界值要不要包含。
5. 常见问题与排查技巧
5.1 规则写了但不生效
这是最常见的问题。原因通常有几个：一是前缀列表没被正确调用，比如route-policy里忘了写if-match，或者BGP邻居上忘了应用route-policy。二是匹配方向搞反了，import和export弄混了。三是序号顺序问题，前面的规则把后面的规则挡住了。
排查方法：先用display ip ip-prefix看计数，如果计数是0，说明没有路由匹配上，检查规则本身。如果计数不为0但路由还是被过滤了，检查route-policy的node顺序和动作。如果route-policy也没问题，检查BGP邻居上是否应用了正确的策略。
5.2 掩码长度匹配不上
这个问题的根源通常是对 greater-equal 和 less-equal 的理解有偏差。记住一个原则：前面写的掩码长度是"基准"，greater-equal 和 less-equal 是在这个基准上做范围扩展。比如permit 10.1.0.0 16 less-equal 24，意思是网络地址匹配 10.1.0.0/16，掩码长度在16到24之间。
如果你写permit 10.1.0.0 24 less-equal 16，这是非法的，因为16小于24。设备会报错：Error: The less-equal value must be greater than or equal to the mask length.
还有一个容易忽略的点：如果你只写网络地址不写掩码长度，比如permit 10.1.0.0，它匹配的是所有以 10.1.0.0 开头的路由，掩码长度不限。这个用法要慎用，容易误放行。
5.3 隐式拒绝导致的意外过滤
前面提过，前缀列表末尾有隐式deny。很多人写规则的时候只写了permit，忘了考虑没匹配上的路由会被拒绝。比如你写permit 10.1.0.0 16，结果来了一条 10.1.0.0/24 的路由，匹配不上，被隐式拒绝。如果你本意是放行所有 10.1.0.0 开头的路由，那就应该写permit 10.1.0.0 16 less-equal 32。
我的习惯是：在写完permit规则后，如果需求是"放行多数、拒绝少数"，就在末尾加一条permit 0.0.0.0 0 less-equal 32放行所有。如果需求是"拒绝多数、放行少数"，就不加，让隐式deny生效。
5.4 序号冲突和插入规则
默认序号是10、20、30这样递增的。如果你后来想在10和20之间插一条，可以手动指定序号15。但要注意，如果15已经被占用了，会报错。所以规划序号的时候最好留出间隔，比如用10、20、30，中间留空位。
如果要删除某条规则，用undo ip ip-prefix test-prefix index 10。删除后，其他规则的序号不变。如果要修改某条规则，也是先删再加。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方法 |
|---|---|---|---|
| 规则不生效 | 未调用或调用错误 | 检查route-policy和BGP邻居配置 | 确认if-match和import/export方向 |
| 路由被意外拒绝 | 隐式deny生效 | 查看前缀列表计数 | 末尾加permit 0.0.0.0 0 less-equal 32 |
| 掩码长度匹配不上 | greater/less-equal理解偏差 | 检查规则中的掩码范围 | 调整greater-equal和less-equal的值 |
| 序号冲突 | 手动指定序号重复 | 查看已有规则序号 | 重新规划序号，留出间隔 |
| 部分路由匹配不上 | 网络地址不匹配 | 对比路由网络地址和规则 | 调整规则中的网络地址 |
5.6 几个实操心得
第一个心得：配前缀列表的时候，我习惯先写一条permit 0.0.0.0 0 less-equal 32放在最后，然后再往上加具体的规则。这样做的目的是先保证"默认放行"，然后再逐步收紧。如果反过来，先写拒绝规则再写放行规则，很容易因为隐式deny导致意外过滤。
第二个心得：前缀列表的命名要有意义。比如bgp-in-filter、ospf-out-filter，一看就知道用在哪、什么方向。不要用test1、test2这种名字，过两天自己都忘了是干嘛的。
第三个心得：配完之后一定要用display ip ip-prefix看计数。计数为0的规则要么是写错了，要么是没路由匹配。这个习惯能帮你快速定位问题。
第四个心得：在BGP里做过滤的时候，如果同时用了前缀列表和AS路径过滤，要注意匹配顺序。route-policy里的if-match是"与"的关系，所有条件都匹配才执行动作。如果只想用其中一个条件，就不要写另一个。
6. 进阶用法与场景扩展
6.1 配合AS路径过滤做精细控制
前缀列表单独用已经很强了，但配合AS路径过滤能实现更精细的控制。比如你要拒绝来自某个AS的路由，同时只接收特定网段：
ip ip-prefix bgp-in index 10 permit 10.1.0.0 16 less-equal 24 ip as-path-filter 1 deny _300_ ip as-path-filter 1 permit .* route-policy bgp-filter permit node 10 if-match ip-prefix bgp-in if-match as-path-filter 1这样配置之后，只有同时满足"网段在10.1.0.0/16到/24范围内"和"AS路径中不包含300"的路由才会被接收。两个条件是"与"的关系。
6.2 在路由引入时的过滤
OSPF引入外部路由的时候，也可以用前缀列表做过滤。比如只引入特定的静态路由：
ip ip-prefix import-filter index 10 permit 172.16.0.0 16 less-equal 24 ip ip-prefix import-filter index 20 deny 0.0.0.0 0 less-equal 32 ospf 1 import-route static route-policy import-filter这里route-policy的名字和前缀列表的名字可以一样，也可以不一样。我习惯用不同的名字，避免混淆。
6.3 前缀列表的匹配效率
前缀列表的匹配效率比ACL高，因为它是基于树形结构存储的，查找速度快。但在规则数量很多的时候，还是要注意优化。我的经验是：把最常匹配的规则放在前面，减少匹配次数。比如你有一条规则匹配了90%的路由，就把它放在序号10的位置。
另外，前缀列表的规则数量不宜过多，一般建议控制在几十条以内。如果规则太多，考虑用社区属性或者其他的过滤方式替代。
6.4 和其他过滤工具的对比
| 工具 | 匹配维度 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| ACL | 数据包地址 | 接口过滤、NAT | 简单直观 | 不能匹配掩码长度 |
| 前缀列表 | 路由前缀+掩码 | 路由过滤 | 精确匹配掩码 | 不能匹配数据包 |
| AS路径过滤 | AS路径 | BGP路由过滤 | 灵活匹配AS | 只适用于BGP |
| 社区属性过滤 | 社区属性 | BGP路由过滤 | 可标记路由 | 需要提前规划 |
选择哪个工具，取决于你的具体需求。如果只是过滤数据包，用ACL。如果是过滤路由且需要精确控制掩码，用前缀列表。如果是BGP场景且需要按AS过滤，用AS路径过滤。
7. 我踩过的几个坑
第一个坑：有一次做BGP过滤，我写了一条permit 10.1.0.0 16，本意是放行 10.1.0.0/16 这条汇总路由。结果发现 10.1.1.0/24 这条明细路由也被放行了。我当时很纳闷，后来才想明白：10.1.1.0/24 的网络地址前16位和 10.1.0.0 是一样的，掩码长度24虽然不等于16，但前缀列表在匹配的时候，网络地址部分匹配上了，掩码长度不匹配，按理说应该继续往下查。但问题是，我后面没有其他规则了，隐式deny应该拒绝它才对。为什么会被放行？
后来仔细查文档才发现，我犯了一个低级错误：我把permit 10.1.0.0 16写成了permit 10.1.0.0，没写掩码长度。这样它匹配的是所有以 10.1.0.0 开头的路由，掩码长度不限。所以 10.1.1.0/24 也被放行了。这个坑让我记住了：写前缀列表一定要写掩码长度，除非你确实想匹配所有掩码。
第二个坑：有一次在OSPF里做过滤，我用了filter ip-prefix ospf-filter import，结果发现过滤没生效。排查了半天，发现是方向搞反了。import是过滤进入区域的路由，export是过滤发布出去的路由。我的需求是过滤从区域0进入区域1的路由，应该在区域1的视图下配import。但我配在了区域0的视图下，方向反了。
第三个坑：有一次配前缀列表的时候，我用了默认序号，写了三条规则：10、20、30。后来想在10和20之间插一条，手动指定序号15。结果设备报错，说序号15已经被占用了。我查了一下，发现之前有一条规则用了序号15，但我忘了。这个坑让我养成了习惯：配前缀列表的时候，先display ip ip-prefix看一下已有的序号，再规划新的序号。
第四个坑：有一次做BGP过滤，我用了route-policy，node 10 的动作是permit，if-match调用了前缀列表。结果发现所有路由都被拒绝了。排查后发现，route-policy的node 10 里，if-match没匹配上的路由会继续查下一个node，如果没有下一个node，默认是deny。而我以为route-policy的默认动作是permit。这个坑让我记住了：route-policy的默认动作是deny，不是permit。如果要放行没匹配上的路由，需要在末尾加一个route-policy xxx permit node 100，里面不写if-match，表示匹配所有。
这些坑踩下来，我的体会是：前缀列表本身不复杂，但和route-policy、BGP、OSPF配合使用的时候，细节很多。配完之后一定要验证，用display命令看计数、看路由表，确认过滤效果符合预期。不要想当然，觉得配了就一定生效。
最后分享一个小技巧：如果你不确定前缀列表的匹配效果，可以先在一个测试环境里验证，用display ip ip-prefix看计数，确认每条规则匹配了哪些路由。确认无误后再应用到生产环境。这个习惯能帮你避免很多生产事故。
