BGP路由聚合详解：华为设备原理、配置与实验

打开BGP路由表，我第一眼看的永远是那条“总路由数”。做网络越久越明白，BGP最难熬的不是协议本身，而是路由表大到一定程度之后，设备资源、链路带宽、故障收敛速度全都跟着遭殃。BGP路由聚合就是在这样的背景下被反复提起的：用一条聚合路由代表一堆明细路由，让全世界少记一点东西。这东西在运营商、数据中心出口、企业总部出口都极其常见，今天我就用华为设备把原理和实验一起讲透，从为什么有这玩意儿，到命令怎么敲，再到实验中你会遇到的坑，一条线走完。

1. 为什么要做BGP路由聚合：一张膨胀的路由表背后

1.1 路由表膨胀带来的三个直接压力

全球互联网的IPv4 BGP路由表现在早就超过了九十万条。这个数字听起来抽象，换算成设备压力就非常具体了。

第一是内存压力。每一条BGP路由在路由器里都对应一组属性结构，AS_PATH、社区属性、各类标记，加上各种BGP扩展属性，一条路由消耗的内存远比你想的大。百万级路由的Full Table接收，对一台中端路由器的内存规格来说已经是非常沉重的负担。

第二是CPU压力。BGP邻居每次收到更新，都要跑一遍选路流程，包括属性比较、最优路径计算、路由表刷写。网络抖动频繁的时候，连发更新会集中到达，CPU瞬间冲高，严重的会把设备直接拖垮。

第三是故障收敛变慢。BGP没有周期刷新机制，靠的是增量更新和失效通告。路由条目越多，一次路由震荡要处理的撤销、更新、重计算就越多，全网的收敛时间被无限拉长。

路由聚合要解决的，就是这三件事同时发生时的困境。把多条明细路由收成一条聚合路由对外通告，对端只需要处理一条前缀，内存、CPU、收敛时间全部获利。

1.2 聚合解决的不仅是数量问题

很多刚接触BGP的同学以为聚合只是“把路由变少”，其实这只是最表面的一层。

它更重要的价值是隔离内部震荡。举个例子，某运营商的接入网里有一段链路频繁抖动，对应的几条/24路由在外网翻来覆去。如果这些/24路由直接用BGP通告出去，对端路由器会跟着一起抖，严重的还会被对端策略做惩罚性处理，比如衰减、加惩罚值。做了聚合之后，明细路由的震荡被聚合路由器挡在内部，对外通告的聚合路由始终稳定，外网的BGP邻居无感。这是聚合在工程上最有价值的地方。

第二个隐藏价值是简化路由策略。外部网络只需要对一条聚合路由做过滤、做流量引导、做选路控制，不必为了几十条明细逐条写策略。配置可读性、可维护性都大幅提升。

但是要注意，聚合本质上是一种“信息压缩”，压缩就会丢信息。这引出下一节的核心问题：聚合用什么形式保存被丢失的信息，以及怎么保证不因为信息丢失而出环路。

2. 聚合原理拆解：从前缀压缩到防环逻辑

2.1 聚合的本质是信息压缩

BGP路由聚合的原理，和IP地址规划里的路由汇总很像：用更短的前缀覆盖多条更长的前缀。比如设备上有172.16.1.0/24、172.16.2.0/24、172.16.3.0/24、172.16.4.0/24四条路由，聚合之后对外就通告一条172.16.0.0/22。

这个操作本身不难理解，难的是理解它丢掉的东西。明细路由在传输过程中携带了各自的AS_PATH、MED、Community、Origin等属性，这些属性在聚合路由上不能简单地“合并”成一条。当被聚合的明细路由来自不同AS时，它们的AS_PATH都不一样，聚合路由器怎么填这条聚合路由的AS_PATH？直接选其中一个，还是用一个集合表达？这个问题处理不好，就会产生路由环路。

2.2 atomic-aggregate：主动声明“我的信息不完整”

先看默认情况。华为设备上配置BGP路由聚合时，如果不带as-set参数，聚合路由器会从被聚合的明细路由里选一条，保留它的AS_PATH作为聚合路由的AS_PATH，然后在通告时给聚合路由打上一个原子聚合（ATOMIC_AGGREGATE）属性。

这里的关键点在于：原子聚合属性是一个“声明”，它的含义是——本聚合路由器担保这是一个汇聚结果，而非逐跳传递路径；接收方不应当要求这条路由的AS_PATH提供完整的逐AS环路检测能力。直白点说，就是聚合路由器在告诉对端：我把路径信息压缩了，你要是拿着这条路由往源头转发，别指望靠AS_PATH防环能完全兜底。

原子聚合属性不影响BGP选路，它更像一个“职业警告标签”。收到带有原子聚合属性的路由时，路由器仍然会正常接收、正常选路，但设计路由策略时要意识到：这条路由背后的真实路径信息是不完整的。

2.3 as-set：丢失来自不同AS的路径信息后，靠集合防环

如果被聚合的明细路由来自多个不同的AS，默认聚合方式就危险了。

举个场景：我的设备收到了AS 100通告来的172.16.1.0/24和AS 400通告来的172.16.3.0/24，我把它们聚合成172.16.0.0/22。如果只保留其中一条明细的AS_PATH，假设保留了AS 100，聚合路由通告出去以后是“AS_PATH: 200 100”的样子。一旦这条路由被通告回AS 400的某个邻居，AS 400检查AS_PATH，发现里面只有200和100，没有400，于是它认为自己没见到过这条路由，就会继续接收。等它再通告给别处，环路风险就出现了。

解决办法就是as-set参数。配置了as-set后，聚合路由器会把所有贡献明细路由的AS号放到一个集合里，追加在聚合路由器自己的AS之后，形成类似“200 {100,400}”的AS_PATH结构。{}里的内容就是AS_SET。任何收到这条路由的AS在检查环路时，不仅检查AS_PATH里的普通AS号，还要检查AS_SET集合里的每一个AS号。如果发现自己也在集合中，就默认丢弃这条路由，环路风险被阻断。

换句话说，as-set是用“路径信息打包”的方式，弥补了聚合过程造成的AS路径失真的问题。付出的代价是AS_SET不影响AS_PATH长度计算时被当作一个整体计数，但路由条目一旦收敛，更新和计算量都远小于处理多条明细。

2.4 自动聚合与手动聚合的差别

BGP路由聚合在华为设备上分两条路线。

自动聚合对应summary automatic命令，它的特点是省事，但很“粗糙”。这种聚合会把import-route方式引入BGP的子网路由，按照主类网络边界（A类、B类、C类自然掩码）自动汇总。比如一堆10.x.x.x段的路由引入BGP后，会被汇总成一条10.0.0.0/8。它不会去管实际地址规划合不合理，只按自然分类汇总，所以实际工程中用得非常少。

手动聚合对应aggregate命令，可以自由指定聚合前缀长度，还可以搭配detail-suppressed、as-set等参数做精细控制。实际生产环境里，手动聚合才是主流。下面进入配置命令部分。

3. 华为设备核心配置命令：每个参数背后的取舍

3.1 summary automatic的适用范围很窄

先看命令：

bgp 200 summary automatic

配置这条命令后，本设备通过import-route从IGP、静态路由表里引入到BGP的路由，在通告给BGP邻居时会按主类网络自动聚合。

注意，这条命令对通过network命令发布的路由不生效，对从BGP邻居学来的BGP路由也不生效。很多人在实验里先写了network，又开了summary automatic，结果发现路由一点没汇总，就是这个原因。实际工程中，如果你打算用自动聚合，就必须确认引入方式确实是import-route，而且要接受主类网络边界的聚合结果。

3.2 aggregate手动聚合的使用前提

手动聚合命令是：

bgp 200 aggregate 172.16.0.0 255.255.252.0

这条命令告诉BGP进程：只要我的BGP路由表里存在能被172.16.0.0/22覆盖的明细路由，我就在本地生成一条172.16.0.0/22的聚合路由。

有一个前提条件必须记住：被聚合的明细路由必须在本设备的BGP路由表中是有效的。所谓有效，简单说就是下一跳可达、没有被策略过滤掉、没有处于抑制状态。如果明细路由无效，aggregate命令配了也白配，聚合路由不会生成。

还有一个容易被忽略的点：默认情况下，只配置aggregate时，明细路由依然会继续通告。外部邻居会同时看到聚合路由和所有明细路由。也就是说，如果只配aggregate不做其他处理，外部路由表并没有真正“瘦身”。要让明细消失，必须用detail-suppressed。

3.3 detail-suppressed：真正让外部感知到“聚合”

bgp 200 aggregate 172.16.0.0 255.255.252.0 detail-suppressed

detail-suppressed的含义是：在通告聚合路由的同时，抑制那些被你聚合的明细路由，不再向外通告。

加了这条参数之后，本设备BGP表里的明细路由状态会变成suppressed，也就是被抑制状态。外部BGP邻居只会收到172.16.0.0/22，不会收到那些/24明细。

这里要特别提醒：被抑制的是BGP对外通告，不是本地转发。本设备自己的BGP表里仍然有这些明细路由，仍然可以基于明细路由做本地转发。这个“本地有明细、对外只通告聚合”的状态，正是绝大多数场景下需要的最终效果。真正要用的完整命令形态，往往是聚合加抑制再加as-set一起出现。

3.4 as-set参数补充防环能力

bgp 200 aggregate 172.16.0.0 255.255.252.0 detail-suppressed as-set

这个形态是最常用的。as-set的作用前面原理部分已经讲透了，配置上就是给aggregate命令加一个参数。注意，as-set增加了防环能力，但也可能带来一个副作用：AS集合里的成员发生变化时，聚合路由的AS_PATH也随之变化，这有时会引发路由更新。对邻居少、拓扑简单的实验环境完全没问题，超大网络上要结合具体场景评估。

到这里，配置命令已经全部介绍完。但纸上得来终觉浅，我下面搭一个完全能复现的实验环境，把上述三个场景逐一验证。

4. 实验拓扑与基础搭建：复现一个聚合场景

4.1 拓扑设计与地址规划

我准备了四台华为路由器，模拟一个跨三个AS的网络：

R1属于AS 100，负责通告两条明细路由； R4属于AS 400，负责通告另外两条明细路由； R2属于AS 200，是整个实验的聚合路由器，同时连接R1和R4，并向AS 300通告； R3属于AS 300，作为外部观察者，验证从R2收到的路由。

R1 (AS 100) ── G0/0/0 ── R2 (AS 200) ── G0/0/1 ── R3 (AS 300) 10.0.12.0/24 | 10.0.23.0/24 G0/0/2 10.0.24.0/24 | R4 (AS 400)

地址规划如下：

4.2 BGP邻居关系与明细路由通告

在R1上配置：

interface GigabitEthernet0/0/0 ip address 10.0.12.1 255.255.255.0 # bgp 100 peer 10.0.12.2 as-number 200 ipv4-family unicast network 172.16.1.0 255.255.255.0 network 172.16.2.0 255.255.255.0 peer 10.0.12.2 enable

在R4上配置：

interface GigabitEthernet0/0/0 ip address 10.0.24.4 255.255.255.0 # bgp 400 peer 10.0.24.2 as-number 200 ipv4-family unicast network 172.16.3.0 255.255.255.0 network 172.16.4.0 255.255.255.0 peer 10.0.24.2 enable

在R2上建立三组eBGP邻居：

interface GigabitEthernet0/0/0 ip address 10.0.12.2 255.255.255.0 # interface GigabitEthernet0/0/1 ip address 10.0.23.2 255.255.255.0 # interface GigabitEthernet0/0/2 ip address 10.0.24.2 255.255.255.0 # bgp 200 peer 10.0.12.1 as-number 100 peer 10.0.23.3 as-number 300 peer 10.0.24.4 as-number 400 ipv4-family unicast peer 10.0.12.1 enable peer 10.0.23.3 enable peer 10.0.24.4 enable

在R3上配置：

interface GigabitEthernet0/0/0 ip address 10.0.23.3 255.255.255.0 # bgp 300 peer 10.0.23.2 as-number 200 ipv4-family unicast peer 10.0.23.2 enable

配置完成后，先确认邻居都建立起来：

display bgp peer

三组eBGP邻居都进入Established状态后，在R3上查看从R2学到的路由：

display bgp routing-table

此时R3应该能看到172.16.1.0/24、172.16.2.0/24、172.16.3.0/24、172.16.4.0/24四条明细路由，AS_PATH分别是100和400。这是聚合实验的初始状态。

4.3 聚合器上的“聚合前提检查”

在R2上执行：

display bgp routing-table

正常情况下，R2的BGP表里应该存在R1和R4通告过来的四条/24明细，全部处于“*>”状态，表示有效且被使用。这很重要，因为聚合的前提就是这些明细在本设备BGP表中必须有效。

确认无误后，我们进入聚合配置阶段。实验我会分三场做，每场改一个参数，对比效果。

5. 三种聚合场景的实测记录

5.1 场景一：只配置基础手动聚合

在R2的BGP视图下增加聚合命令：

bgp 200 ipv4-family unicast aggregate 172.16.0.0 255.255.252.0

配置后回到R3，再次查看BGP路由表：

display bgp routing-table

此时R3应该同时看到五条路由：一条172.16.0.0/22聚合路由，以及原来那四条/24明细路由。聚合路由的AS_PATH显示为200，NextHop指向10.0.23.2。

这个结果验证了我前面强调的点：基础聚合只是“多生成了一条聚合路由”，明细路由并不会自动消失。很多第一次做实验的朋友在这里会产生误解，以为配置完聚合后对端只剩一条路由，结果发现明细还在，以为自己配错了。其实不是配错了，而是默认行为就是这样。

从运营角度看，只配聚合的价值是让网络里存在一条“汇总后的路由”，供某些场景下做策略匹配或简化选路。但要让外部真正减少路由条目，必须要走场景二。

5.2 场景二：加detail-suppressed抑制明细

在R2上把聚合命令改为：

bgp 200 ipv4-family unicast aggregate 172.16.0.0 255.255.252.0 detail-suppressed

回到R2执行：

display bgp routing-table

你会看到172.16.1.0/24到172.16.4.0/24这一排的状态码里多了一个“s”，这个状态就是suppressed，被抑制。明细路由仍然存在于BGP表，用于本地转发和聚合，但不会再发给BGP邻居。

再到R3上查看：

display bgp routing-table

此时R3的BGP表里只剩一条172.16.0.0/22聚合路由，四条/24明细全部消失。这才是对外真正生效的聚合。

这里我额外提一个实验上常见的困惑：有些版本的设备在修改聚合参数后，对端不会立刻看到清除的明细路由。这是因为BGP的更新通告有一定延迟，或者需要刷新会话。遇到这种情况，可以执行软刷新让聚合路由器重新对外通告一次：

refresh bgp 10.0.23.3 export

如果环境支持，也可以在对端执行：

refresh bgp 10.0.23.2 import

软刷新比直接重置BGP会话温和得多，不会造成会话中断，这在现网操作里非常重要。

5.3 场景三：as-set对AS_PATH的影响

现在做一个关键对比实验。先把detail-suppressed去掉，只保留基础聚合：

bgp 200 ipv4-family unicast aggregate 172.16.0.0 255.255.252.0

此时回到R3看路由：

display bgp routing-table 172.16.0.0 255.255.252.0

因为R2从AS 100和AS 400都学到了明细，聚合路由器在生成聚合路由时，会从这些明细里挑选一条的AS_PATH作为聚合路由的AS_PATH。在本实验中，你会看到AS_PATH值为200 100，或者200 400。不管挑了哪条，对AS 300来说，这条聚合路由的AS_PATH都不能完整反映它所覆盖的真实路径。

接着加上as-set：

bgp 200 ipv4-family unicast aggregate 172.16.0.0 255.255.252.0 as-set

再回R3查看这条聚合路由，AS_PATH会变成类似“200 {100,400}”的结构。{}里的AS号就是AS_SET，它告诉所有下游：这条聚合路由实际上由AS 100和AS 400的明细路由聚合而来。

不要小看这个变化。如果没有as-set，前面原理部分分析的环路风险是完全真实存在的。一旦这条聚合路由被通告回AS 100或AS 400，它们检查自己的AS号不在AS_PATH里，就会继续接收、继续转发，环路就这么形成了。而有了as-set后，路由被通告回AS 100时，AS 100在AS_SET里看到自己的编号，直接丢弃，环路被从机制上掐断。

5.4 接收端的验证与查看方法

做聚合实验时，R3上的几个查看命令要熟练掌握。

查看全部路由，用：

display bgp routing-table

只看某一条路由的详细信息，用：

display bgp routing-table 172.16.0.0 255.255.252.0

里面可以看到聚合路由的AS_PATH、NextHop、Origin、LocalPref等完整属性。想看这条聚合路由到底汇聚了哪些明细，可以在R2上确认被抑制状态：

display bgp routing-table 172.16.1.0 255.255.255.0

此外，如果需要看聚合路由在更新报文中实际带出去的属性，可以从R3侧抓包或执行debug，但一般通过路由表查看AS_PATH就足够验证as-set是否生效了。

6. 实操中容易踩的坑与排错链路

6.1 聚合路由不生效，先查本地明细是否有效

拿到“聚合路由没生成”的问题，先别急着怀疑命令写错。第一件事是到聚合路由器上执行：

display bgp routing-table

确认被聚合的明细路由是否存在，状态是否为“*>”且前缀长度正确。只要明细路由无效，aggregate就不会生成聚合路由。

什么情况会导致明细无效？最常见三种：BGP邻居没起来、明细路由被策略过滤、下一跳不可达。尤其下一跳可达这个条件经常被忽略——哪怕你是通过network发布的直连路由，如果对端把下一跳给过滤了，本设备认为下一跳不可达，路由就会变成无效，聚合也就无从谈起。

排查时按顺序来：先看BGP邻居状态，再看路由表里明细的下一跳，再用ping验证聚合路由器和明细源之间的三层连通性。链路通了，路由有效了，聚合路由通常自然就出来了。

6.2 聚合后的路由黑洞，源头在“本地明细缺失”

聚合最危险的坑，是路由黑洞。

场景是这样：聚合路由器把172.16.0.0/22通告出去了，同时用detail-suppressed抑制了明细通告。外部来的流量带着172.16.1.1这样的目的地址到达聚合路由器，正常情况下聚合路由器应该按本地BGP表里的172.16.1.0/24明细路由转发。如果本地BGP表里没有这条明细，或者明细下一跳无效，聚合路由器会查不到匹配路径，只能把流量丢掉。

更麻烦的是，如果聚合路由器上只有聚合路由，也就是明细路由压根没进本地路由表的情况，数据包进来后可能匹配到一条默认路由或黑洞静态路由被丢掉，而且排查起来非常隐蔽。

规避方法其实不复杂：在做聚合之前，就要确保聚合路由器自己具备到达明细网络的完整转发路径。要么明细路由就在本设备BGP表中且下一跳可达，要么内部有静态/IGP路由兜底。原则是一句话：对外可以只通告聚合路由，但对内必须知道每条明细怎么走。

6.3 修改聚合参数后对端不刷新，别急着重启会话

很多人在实验里遇到这样的问题：明明在聚合路由器上改了detail-suppressed，对端路由表却还是老样子，于是直接reset BGP，然后整个会话中断，连其他路由也一起抖掉。

这个操作在实验环境没什么，在现网就是事故级别。正确做法是优先使用软刷新，在BGP视图下执行：

refresh bgp 10.0.23.3 export

这个命令会重新通告全部BGP路由给指定对端，对端再跑一遍相关策略，就能看到聚合参数变化后的效果。对端也可以自己主动重新接收：

refresh bgp 10.0.23.2 import

理解一下两者的差别：export是从本端重新发，import是对端主动向本端请求重新学习，效果类似，选一个执行即可。软刷新只重建更新信息，不重建会话，对业务的影响几乎为零。

6.4 summary automatic没生效，多半是通告方式不对

再回到自动聚合，这个坑几乎每天都会有人踩一次。配置summary automatic后，怎么检查都没看到聚合效果，十有八九是路由通告方式用了network命令。

再看一遍命令含义：自动汇总只针对通过import-route引入BGP的路由生效。你用network精确通告的路由，BGP进程会认为这是你主动想发布的前缀，不会拿自动聚合去碰它。想让网络命令发布的路由参与自动聚合，就得改成import-route方式引入，再配合聚合策略定向发布。

这一点在现网规划时要提前想明白，不然等配置上线再发现行为不符合预期，来回排查折腾的时间够喝好几杯咖啡了。

最后再分享一句实在话

做过几次聚合实验后，我的体会是：BGP路由聚合的难点从来不在命令本身，而在“你想让外面看到什么，你想让内部知道什么”这两个问题之间的平衡。聚合提高了稳定性、降低了路由规模，但代价是路径信息被压缩、故障域被隐藏，as-set和detail-suppressed这两个参数，就是帮你重新找回这种平衡的钥匙。实验环境里多折腾几轮，先把聚合不生效、明细消失、AS路径改变这些现象都亲眼看一遍，现网里再遇到相关故障，心里就有底了。