FRRouting Route Maps实战：路由重分发策略与防环配置指南

1. 路由映射到底在解决什么问题

刚接触FRRouting那会儿，我对Route Maps的理解一直停留在“就是个过滤工具”的层面，直到有一次在实验室里做路由重分发实验，才发现这东西远不止过滤那么简单。Route Maps在FRR里扮演的角色，更像是一个路由策略的编排引擎——它决定了哪些路由可以被引入、引入后带什么属性、优先级怎么调、下一跳怎么改。你可以把它理解成网络世界的“交通规则制定者”，每条规则告诉路由器：遇到什么样的流量，该放行、该拦截、还是该改道。

这个机制的核心价值在于精细化控制。传统的ACL只能做“允许或拒绝”的二值判断，而Route Maps可以基于源地址、目的地址、下一跳、度量值、路由类型、团体属性等一大堆条件做匹配，匹配之后还能执行修改操作。这就好比ACL是小区门禁，只认脸放行；Route Maps则是机场安检加海关，不仅要查证件，还要开箱检查、贴标签、决定你走哪个通道。

适合阅读这篇内容的人，我大致分三类：第一类是正在备考网络方向认证、需要动手做实验的学员；第二类是在实际项目中需要做路由策略优化的运维工程师；第三类是对FRR感兴趣、想从零搭建路由实验环境的技术爱好者。不管你属于哪一类，只要跟着下面的思路走，都能把Route Maps从“知道有这么个东西”变成“能上手配、能排错、能优化”。

2. Route Maps的核心机制与匹配逻辑拆解

2.1 一条Route Map语句的解剖结构

Route Maps在FRR里的语法结构看起来简单，但每一部分都有讲究。一条典型的Route Map语句长这样：

route-map MY_POLICY permit 10 match ip address prefix-list MY_PREFIX match metric 100 set local-preference 200 set community 65001:100

拆开来看，route-map是关键字，MY_POLICY是策略名称，permit是动作，10是序号。这四个元素构成了Route Map的“身份证”。策略名称用来在调用时引用，动作决定匹配后是放行还是丢弃，序号决定匹配顺序。

这里有个容易被忽略的细节：序号不是随便编的，它决定了匹配的先后顺序。FRR会从序号最小的语句开始逐条匹配，一旦某条语句匹配成功，就执行对应的set操作，然后不再继续往下匹配。这个行为和ACL的“首次匹配即生效”是一个逻辑。很多人配置完发现策略没生效，排查半天才发现是序号排错了，小序号的语句把流量全截走了。

提示：序号建议以10为步长递增，比如10、20、30。这样后续需要在中间插入新语句时，不用重新编号所有条目。

2.2 permit与deny的隐藏语义

permit和deny这两个动作，表面上看是“允许”和“拒绝”，但在Route Maps的语境下，它们的含义要复杂一层。当你写了一条permit语句但没有任何match条件时，它表示“匹配所有”。这个特性经常被用来做“兜底放行”——在策略末尾加一条空的permit语句，确保没有被前面规则匹配到的路由不会被隐式丢弃。

而deny语句的行为更微妙。如果一条路由被deny语句匹配到，它不仅会被拒绝，而且后续的Route Map语句也不会再对它进行评估。这意味着deny是一个“终止性”动作。我见过有人在策略中间插了一条deny想过滤特定路由，结果把后面本该放行的流量也一起干掉了，就是因为没理解这个终止逻辑。

还有一个隐式规则：如果一条路由走完了所有Route Map语句都没有被任何一条匹配，默认行为是deny。这个和ACL的隐式拒绝是一样的。所以实际配置中，几乎都会在末尾加一条route-map NAME permit 999来兜底。

2.3 match条件的组合逻辑

match条件是Route Maps的“筛选器”，FRR支持的条件类型相当丰富。我整理了一张常用match条件的对照表：

这里的关键点是同一条Route Map语句内的多个match条件是“与”关系。也就是说，match ip address和match metric同时存在时，路由必须同时满足两个条件才算匹配。但不同序号的语句之间是“或”关系——第一条不匹配就试第二条，第二条不匹配就试第三条。

这个逻辑用生活化的例子解释就是：你去相亲，第一条规则要求“身高180以上且收入50万以上”，两个条件都满足才能进入下一轮；如果第一条没通过，就看第二条规则“身高175以上且有房”，以此类推。每条规则内部是“且”，规则之间是“或”。

2.4 set操作的执行时机

set操作是Route Maps的“执行器”，匹配成功后对路由属性进行修改。常见的set操作包括：

• set local-preference：修改BGP本地优先级
• set metric：修改度量值
• set community：设置BGP团体属性
• set ip next-hop：修改下一跳
• set tag：设置路由标签
• set weight：修改BGP权重

set操作的执行时机是在match成功之后、路由被放行之前。这里有个实操中容易踩的坑：set操作修改的是路由的属性，而不是数据包的属性。也就是说，它影响的是路由表里的条目，进而影响后续的转发决策，而不是直接修改经过路由器的数据包。这个区别在排查问题时非常重要——如果你发现数据包没按预期走，先检查路由表里的条目属性对不对，而不是去抓包看数据包本身。

3. 从零搭建Route Maps实验环境

3.1 实验拓扑设计与地址规划

光看语法容易忘，动手配一遍才是真的。我设计了一个最小化的实验拓扑，用三台FRR路由器搭一个三角结构，足够演示Route Maps的绝大多数用法。

拓扑结构是这样的：R1和R2之间跑OSPF，R2和R3之间跑BGP，R1上有一条静态路由需要通过Route Maps重分发到OSPF，再由R2重分发到BGP传给R3。这样一条路由从静态到OSPF再到BGP，中间经过两次重分发，正好可以演示Route Maps在不同协议边界上的作用。

地址规划如下：

这个拓扑的好处是足够简单，一台普通电脑跑三个FRR容器就能搞定，不需要复杂的硬件环境。我用的是Docker部署FRR，每个容器相当于一台路由器，网络配置用Linux的veth pair连接。

3.2 FRR基础配置与协议启用

先搞定R1的基础配置。FRR的配置文件和Cisco风格很像，但有一些细节差异。启动FRR后，进入vtysh命令行：

# 进入配置模式 configure terminal # 配置接口地址 interface eth0 ip address 10.0.1.1/24 no shutdown exit interface lo ip address 192.168.1.1/32 exit # 启用OSPF router ospf network 10.0.1.0/24 area 0 redistribute static route-map STATIC_TO_OSPF exit # 配置静态路由 ip route 192.168.1.0/24 Null0

注意最后那条静态路由指向Null0，这是一个常用技巧——用来产生一条“占位”路由，方便后续重分发。实际环境中这条路由可能指向真实的下一跳，但在实验里指向Null0就够了。

R2的配置稍微复杂一点，它要同时跑OSPF和BGP，并且做双向重分发：

# OSPF配置 router ospf network 10.0.1.0/24 area 0 redistribute bgp route-map BGP_TO_OSPF exit # BGP配置 router bgp 65001 neighbor 10.0.2.3 remote-as 65002 redistribute ospf route-map OSPF_TO_BGP exit

R3的配置最简单，只需要跑BGP接收路由：

router bgp 65002 neighbor 10.0.2.2 remote-as 65001 exit

这套配置跑起来之后，R3应该能学到R1的192.168.1.0/24路由。但这时候还没有加任何Route Maps策略，路由是“裸奔”状态。接下来才是重点——用Route Maps给这条路由加上各种策略控制。

3.3 验证基础连通性与路由表

配置完成后，先别急着上Route Maps，确认基础路由已经通了。在R3上执行：

show ip route bgp

如果看到192.168.1.0/24出现在BGP路由表里，说明基础重分发没问题。如果没看到，先排查这几个点：R1的静态路由有没有生效、OSPF邻居有没有建立、BGP邻居有没有建立、重分发命令有没有写对。

我踩过的一个坑是：FRR默认不会重分发静态路由到OSPF，除非显式配置redistribute static。而且如果没有route-map参数，它会重分发所有静态路由，包括那些你不想要的。所以在生产环境里，重分发一定要带route-map，这是基本的安全习惯。

4. Route Maps在重分发场景中的实战配置

4.1 用Route Maps控制静态路由重分发到OSPF

现在给R1加上Route Maps，只允许特定的静态路由进入OSPF。假设我们只允许192.168.1.0/24进入，其他静态路由一律不放行：

# 定义前缀列表 ip prefix-list ALLOW_STATIC seq 10 permit 192.168.1.0/24 # 定义Route Map route-map STATIC_TO_OSPF permit 10 match ip address prefix-list ALLOW_STATIC set metric 100 set tag 1001 exit route-map STATIC_TO_OSPF deny 20 exit

这段配置的逻辑是：第一条语句匹配前缀列表里的路由，匹配成功后设置度量值为100、标签为1001，然后放行；第二条语句拒绝所有其他路由。注意第二条deny语句没有match条件，表示匹配所有剩余路由。

这里有个细节值得展开：set metric在OSPF重分发中的作用。OSPF默认给重分发进来的路由设置的度量值是20（对于E2类型路由），这个值会影响路由选择的优先级。手动设置一个更大的值（比如100），可以确保这条外部路由不会抢走内部路由的流量。这个技巧在双点重分发的场景里特别有用，可以避免次优路径。

配置完成后，在R2上查看OSPF外部路由：

show ip route ospf

应该能看到192.168.1.0/24以O E2的形式出现，度量值是100，标签是1001。如果度量值还是默认的20，说明Route Maps没生效，检查一下route-map名称有没有拼错、prefix-list有没有匹配上。

4.2 用Route Maps控制OSPF到BGP的重分发

R2上的重分发更复杂一些，因为OSPF和BGP之间的重分发需要特别注意防止路由环路。我的做法是用Route Maps给从OSPF进入BGP的路由打上团体属性，这样在BGP对等体上可以基于团体属性做策略：

# 定义团体列表 ip community-list standard FROM_OSPF permit 65001:100 # 定义Route Map route-map OSPF_TO_BGP permit 10 match ip address prefix-list OSPF_ROUTES set community 65001:100 set metric 200 exit route-map OSPF_TO_BGP deny 20 exit # 前缀列表 ip prefix-list OSPF_ROUTES seq 10 permit 192.168.1.0/24

这里set community的作用是给路由打一个“来源标记”，R3收到之后可以根据这个标记决定怎么处理。比如R3可以配置一条策略，把带有65001:100团体属性的路由优先级调低，或者直接过滤掉。

set metric 200的作用是设置BGP的MED值，影响R3的选路决策。MED值越小越优先，设置200是一个相对保守的值，确保这条路由不会抢占R3上其他更优路径。

4.3 双向重分发的防环策略

双向重分发是网络工程里的经典难题。如果不加控制，R1的静态路由进入OSPF，R2把它重分发到BGP，R3又可能把它传回BGP，形成环路。Route Maps在这里的作用是“打标记”和“查标记”。

我的做法是在R2上配置两条Route Maps：一条用于OSPF到BGP的重分发，给路由打上团体属性；另一条用于BGP到OSPF的重分发，检查团体属性，如果发现是自己打出去的标记，就拒绝：

# BGP到OSPF的重分发 route-map BGP_TO_OSPF deny 10 match community FROM_OSPF exit route-map BGP_TO_OSPF permit 20 set metric 300 exit

这段配置的逻辑是：第一条语句检查团体属性，如果匹配FROM_OSPF（也就是自己之前打出去的标记），就拒绝，防止环路；第二条语句放行其他路由，并设置度量值为300。

这个“打标记-查标记”的模式是双向重分发的标准做法，几乎在所有多协议网络里都会用到。Route Maps在这里的价值就是提供了打标记和查标记的能力，而且可以精确控制哪些路由打什么标记。

5. Route Maps进阶用法与性能优化

5.1 基于团体属性的路由控制

BGP团体属性是Route Maps最强大的搭档之一。团体属性本质上是一个32位的标签，可以附加在BGP路由上，用来传递策略信息。常见的用法包括：

• 标记路由来源：比如65001:100表示来自OSPF，65001:200表示来自静态
• 标记路由优先级：比如65001:10表示高优先级，65001:20表示低优先级
• 标记路由目的地：比如65001:1表示去往数据中心，65001:2表示去往分支机构

配置团体属性需要先定义community-list：

ip community-list standard HIGH_PRIORITY permit 65001:10 ip community-list standard LOW_PRIORITY permit 65001:20

然后在Route Maps里引用：

route-map SET_PRIORITY permit 10 match ip address prefix-list CRITICAL_ROUTES set community 65001:10 additive exit

注意additive关键字——它表示在原有团体属性基础上追加，而不是覆盖。如果不加additive，原有的团体属性会被清空。这个细节在实际配置中很容易被忽略，导致路由丢失原有的标记信息。

5.2 用continue语句实现多级匹配

FRR的Route Maps支持continue语句，这是一个比较高级的用法。默认情况下，Route Maps匹配到第一条语句后就停止；但加上continue之后，可以继续匹配下一条语句，实现“多重处理”：

route-map MULTI_STEP permit 10 match ip address prefix-list STEP1 set community 65001:10 on-match continue exit route-map MULTI_STEP permit 20 match ip address prefix-list STEP2 set metric 500 exit

这段配置的效果是：如果路由同时匹配STEP1和STEP2，它会先被打上65001:10的团体属性，然后继续匹配第二条语句，再被设置度量值为500。如果不加continue，匹配完第一条就结束了，第二条根本不会执行。

continue语句的典型应用场景是“先打标记再改属性”——比如先给路由打上来源标记，然后根据标记设置不同的度量值。这个模式在大型网络里非常实用，可以把复杂的策略拆解成多个简单的步骤。

5.3 Route Maps的性能考量

Route Maps虽然强大，但也不是没有代价。每一条Route Map语句都需要路由器做一次匹配运算，语句越多、match条件越复杂，消耗的CPU资源就越多。在路由条目数量大的场景下（比如全表BGP），Route Maps的性能影响不可忽视。

我做过一个简单的测试：在FRR上配置100条Route Map语句，每条语句匹配一个不同的前缀列表，然后观察路由收敛时间。结果是收敛时间比不加Route Maps时增加了大约30%。这个数字在小型网络里无所谓，但在大型网络里就需要认真对待了。

优化的思路有几个：第一，尽量用prefix-list而不是ACL，prefix-list的匹配效率更高；第二，把最常用的匹配条件放在前面，减少不必要的匹配次数；第三，合并相似的语句，比如把多个单前缀的match合并成一个prefix-list；第四，避免在Route Maps里做复杂的正则匹配，正则表达式的开销远大于普通字符串匹配。

提示：如果发现Route Maps导致CPU占用过高，可以用show route-map命令查看每条语句的匹配计数，找出命中率低但消耗大的语句进行优化。

6. 常见问题排查与避坑指南

6.1 Route Maps不生效的排查思路

Route Maps配了但没生效，这是最常见的问题。我总结了一个排查流程，按顺序检查基本能定位到原因：

我遇到最多的坑是第4条——序号顺序问题。有一次我配了一条route-map TEST deny 5想过滤特定路由，结果把后面所有permit语句都架空了，因为deny 5的序号最小，所有路由先被它匹配，匹配到就终止了。后来把deny语句的序号改成100，问题解决。

6.2 set操作不生效的原因分析

set操作配了但路由属性没变，这个问题比match不生效更隐蔽。常见原因有：

• set操作在deny语句里：deny语句匹配后直接拒绝，不会执行set操作。set只能写在permit语句里。
• set操作被后续语句覆盖：如果路由匹配了多条permit语句（用了continue），后面的set会覆盖前面的。
• set操作的值超出范围：比如local-preference的范围是0-4294967295，设成负数就不生效。
• 协议不支持该属性：比如在OSPF里set community是无效的，因为OSPF没有团体属性这个概念。

排查set操作问题，最直接的方法是在R2上show ip bgp查看路由的详细属性，对比配置前后的变化。如果属性没变，就逐条检查上面的原因。

6.3 重分发场景下的路由环路识别

路由环路是重分发场景里最危险的问题，轻则网络性能下降，重则全网瘫痪。识别环路的信号包括：路由的度量值不断增大、路由在多个协议之间反复跳转、traceroute显示路径循环。

Route Maps防环的核心思路是“标记+过滤”。标记的方式可以是团体属性、标签、或者度量值。过滤的方式就是在重分发入口检查标记，发现是自己的标记就拒绝。

我个人的经验是：双向重分发一定要配Route Maps，而且一定要在两端都配。只在一边配防环策略，另一边不配，环路风险依然存在。另外，防环策略要定期验证——网络拓扑变化后，原来的防环策略可能不再适用，需要重新评估。

6.4 Route Maps与分发列表的配合使用

Route Maps和分发列表（distribute-list）经常一起使用，但它们的职责不同。分发列表用于过滤路由更新，Route Maps用于修改路由属性。在实际配置中，通常是先用分发列表做粗粒度过滤，再用Route Maps做细粒度控制。

比如在OSPF里，可以用分发列表阻止某些路由进入路由表，同时用Route Maps修改其他路由的度量值：

router ospf distribute-list prefix-list BLOCK_ROUTES in redistribute static route-map MODIFY_METRIC exit

这种配合使用的方式可以兼顾性能和灵活性。分发列表的过滤效率高，适合处理大量路由；Route Maps的修改能力强，适合处理需要精细控制的少量路由。

7. 我在实际项目中的几点体会

Route Maps这个东西，看文档觉得简单，真正配起来才知道细节多。我印象最深的一次是做一个跨协议重分发的项目，R1跑OSPF、R2跑BGP、R3跑静态，中间用Route Maps做策略控制。配置写完之后测试，发现R3学到的路由度量值不对，排查了两个小时才发现是R2上的一条Route Map语句序号排错了，小序号的permit语句把流量截走了，后面的set metric根本没执行。

从那以后我养成了一个习惯：每配完一条Route Map，立刻用show route-map命令确认匹配计数。如果某条语句的匹配计数是0，说明它根本没被命中，要么是match条件写错了，要么是被前面的语句拦截了。这个习惯帮我省了很多排查时间。

另一个体会是：Route Maps的注释很重要。FRR的配置文件支持!开头的注释行，我习惯在每条Route Map语句上面加一行注释，说明这条语句的用途和匹配逻辑。过几个月再回来看配置，没有注释的话根本记不住当时为什么这么写。

最后分享一个小技巧：如果需要在多条Route Map之间共享前缀列表或团体列表，可以把它们定义在全局配置里，然后在Route Maps里引用。这样修改前缀列表时只需要改一处，所有引用它的Route Maps都会自动生效。这个做法在大型网络里特别有用，可以避免遗漏和 inconsistency。