做网络运维这行只要手上管过公网出口或者跨域互联早晚会撞上路由表条目数这道坎。我最早认真对待BGP手动聚合是被一条告警逼出来的某台边界设备的BGP邻居前缀数在两小时里从四万多涨到六万多CPU占用直接拉到七成以上敲一条show命令要等三秒才出结果。排查下去问题不在链路也不在攻击而是下游一个分支站点把十几条连续的/24明细一股脑全灌了进来——它自己觉得没什么对上游来说就是十几条新增前缀而这样的站点有二十几个。这件事之后我把aggregate-address这条命令的每个参数重新拆了一遍。所谓BGP手动聚合说白了就是在边界设备上手工指定一个聚合前缀把10.1.0.0/24到10.1.3.0/24这几条明细汇总成一条10.1.0.0/22让邻居只看到这一条汇总路由。它解决的核心问题是三个路由表规模、明细频繁抖动带来的路由翻动、以及对外宣告时我到底持有哪些网段这个语义的收敛。需要先说清楚一点聚合不是把路由藏起来也不是省事儿的过滤器。它是一次有代价的路由语义重写——你把精确信息换成了粗略信息换来的是规模和稳定性代价是故障定位变难、流量工程受限、以及可能引入黑洞。所以这篇文章不打算只给你命令我按为什么这么设计—参数到底在干什么—怎么配—配完怎么验—出事怎么查这条线走一遍。管边界路由器的人、做多线出口的人、做机房互联的人还有被as-set和atomic-aggregate这两个词绕晕、准备走认证路线的朋友都能从里面找到能直接抄的东西。1. 先把手动聚合这件事说清楚它到底在解决什么问题1.1 从一张被明细灌爆的路由表说起我见过太多团队把聚合当成一条顺手加上的命令配置在变更单上只有一行备注写优化路由表。但这种加法往往没想清楚代价。要理解手动聚合得先理解一台边界设备的BGP表是怎么被撑大的本地所有宣告出去的网段、从上游学来的全表、从各个分支站点学来的明细三者叠加。全表部分你无法控制但自己宣告出去的那部分完全是可控的。明细路由为什么会被灌进来因为很多接入侧设备的配置习惯是有多少网段就network多少条或者从IGP重分发时不加汇总。一个站点有八个连续/24它就宣告八条二十个这样的站点就是一百六十条。对上游来说它不关心你这八条各自走哪里它只关心到你这个AS怎么走。一百六十条明细和二十条汇总对上游的转发行为几乎没有区别但对路由表、对更新报文、对收敛时间的影响是数量级的差异。更要命的是明细会抖。某个站点的某条/24因为链路闪断撤销又重建上游就要处理一次更新如果这条明细在你这里被聚合成一条汇总那么只要汇总前缀范围内还有别的明细存在汇总路由本身不会撤销上游什么都感知不到。这就是聚合最核心的价值——它把明细的抖动吸收掉了让上游看到的拓扑变得迟钝而稳定。1.2 手动聚合、自动聚合和IGP聚合三者不是一回事这三个概念经常被混为一谈我在排障时被问过无数次。先把边界划清楚**自动聚合auto-summary**是早期BGP的一个老特性它会把重分发进来的子网自动汇总到有类边界A类/B类/C类。这玩意儿在今天基本是默认关闭的因为无类路由才是常态开着它只会制造莫名其妙的路由。我建议所有新设备上手第一件事就是确认它关着。IGP聚合是在OSPF、IS-IS这类协议内部做区域间汇总目的是控制区域内LSA/LSP的数量。它影响的是IGP的链路状态数据库规模。BGP手动聚合是在BGP进程里显式指定聚合前缀影响的是BGP的路径信息和对外宣告内容。它依赖BGP表里存在对应的明细路由才会生成。用生活化的类比IGP聚合像是把小区内部每栋楼的门牌号汇总成几号楼只在小区内部用BGP手动聚合像是给外面寄快递时只写某某小区而不写具体门牌收件方只知道大概位置。两者作用的范围完全不同不能互相替代。对比项自动聚合IGP聚合BGP手动聚合触发方式重分发时自动按有类边界汇总区域边界或指定汇总点手工配置聚合前缀依赖明细是是是默认行为可控性极低中等高可按条件抑制或宣告现代网络中的建议关闭按需使用边界必须规划主要风险意外改变宣告范围区域间次优路径黑洞、流量工程失效1.3 什么场景必须做聚合什么场景千万别碰不是所有环境都适合聚合。我总结了几条判断标准都是从事故里换来的。该做的情况你有大量连续的、归属清晰的地址块需要对外宣告你的明细路由来自多个接入站点且抖动频繁上游对你宣告的前缀数量有明确限制你有多条出口但对外希望呈现为单一入口语义。不该做、或者要极其谨慎的情况你有多条出口且明细分别走不同上游需要靠明细做流量工程你的地址块中间有洞即聚合范围内包含别人在用的地址上游对你做了严格的前缀来源校验而你只申报了明细没申报汇总你对故障定位的时效要求极高不能接受看到汇总但不知道是哪条明细出问题。最后一条我特别有感触。有一次割接后某个业务访问慢抓包发现回程流量全从一条链路回来查了半天才发现是聚合把原本分摊在两条链路上的明细合并了回程路径失去了多样性。这就是典型的聚合破坏流量工程——它让入向流量失去了按明细分流的能力。所以每次做聚合之前我都会问一句这个前缀范围里的明细回程路径是不是一致的不一致就别聚或者只聚一部分。2. 聚合前缀怎么算掩码计算的完整推导过程2.1 二进制对齐找出所有明细的公共前缀这是所有聚合工作的地基算错了后面全错。方法很朴素把所有明细地址写成二进制从左往右找公共的位数公共位数加上原来的网络位长度就是聚合后的掩码长度。拿最常见的例子10.1.0.0/24、10.1.1.0/24、10.1.2.0/24、10.1.3.0/24。前两个八位组10.1完全相同差异在第三个八位组0、1、2、3写成八位二进制分别是00000000、00000001、00000010、00000011。从左往右看前六位都是0第七位开始分化0和1都有。所以公共前缀是6位聚合掩码长度 24 (8 - 6) 22。聚合地址取公共前缀补零得到10.1.0.0/22十进制掩码255.255.252.0。我习惯在纸上或者记事本里画成竖排对比比心算靠谱得多10.1.0.0/24 - 第三个八位组 00000000 10.1.1.0/24 - 第三个八位组 00000001 10.1.2.0/24 - 第三个八位组 00000010 10.1.3.0/24 - 第三个八位组 00000011 ^^ 从这一位开始不一致 公共前缀 6 位 - /24 6 /22只有两条明细的情况10.1.0.0/24和10.1.1.0/24第三个八位组是00000000和00000001公共前缀7位聚合结果10.1.0.0/23掩码255.255.254.0。这个很多人算错过以为两条/24只能聚成/23这是对的但如果三条/240、1、2也往/23聚就会漏掉2那条因为2的二进制是00000010和0、1在第七位就不一致了。三条只能聚成/22代价是包含了3这条不存在的地址。2.2 三个典型例子跨八位组、非2的幂、边界对齐例一跨八位组的对齐。172.16.8.0/24到172.16.15.0/24共八条。第三个八位组8到15二进制00001000到00001111前五位一致聚合掩码24327不对这里要小心8的二进制是0000100015是00001111前五位是00001第六位开始不一致。所以公共前缀5位聚合掩码 24 (8 - 5) 21结果172.16.8.0/21。这类以8的倍数开头的块很好算直接看第三个八位组能被几整除。8到15正好是8个/24对应/21是标准对齐的。例二非2的幂数量。假设你手上有10.1.4.0/24、10.1.5.0/24、10.1.6.0/24三条想聚成一条。前两条可以合成10.1.4.0/23但加上第三条就必须扩到10.1.4.0/22而这个/22覆盖了10.1.4.0到10.1.7.255其中10.1.7.0/24并不属于你。这就是洞。正确做法有两种一是拆成两条宣告10.1.4.0/23加10.1.6.0/24一共两条比三条省一条二是先确认10.1.7.0/24到底在谁手上如果确定没人用且未来可能划给你那聚成/22并做好记录也可以但这是有风险的赌注。例三多地出口的聚合边界。如果明细来自不同机房聚合前缀的边界一定要落在你实际控制的地址块边界上。我曾经见过有人把10.1.0.0/24到10.1.7.0/24聚成10.1.0.0/21但10.1.6.0/24其实是另一个团队在用、走另一条链路。聚完之后外部回程全部落到同一入口那半个/24的业务直接受影响。这种事故排查起来极费时间因为从路由表上看一切正常。2.3 聚合前必须做的三项检查算完前缀别急着配先过三道检查能挡掉八成事故。第一项明细是否齐全。聚合路由是条件生成的——BGP表里得至少有一条落在聚合范围内的明细聚合路由才会存在并被宣告。如果某段时间所有明细都撤销了聚合路由也跟着消失上游会看到一次大范围的路由撤销影响面比原来明细撤销还大。这一点后面还会展开。第二项聚合范围内有没有洞。拿一个地址规划表或者IPAM系统把聚合前缀覆盖的整个地址空间列出来逐段核对归属。凡是不属于自己但被覆盖的都要标红。第三项上游是否接受这个前缀长度。很多上游会对客户宣告做前缀长度过滤常见策略是只接受/8到/24之间的前缀更长或更短都拒。你聚出一个/25或者/7上游直接丢弃而你在本地show advertised-routes里还能看到它特别容易误判。上线前一定要跟对端确认策略或者在试验邻居上先发一条试试。3. 关键参数逐个拆summary-only、as-set、atomic-aggregate3.1 summary-only抑制明细的双刃剑aggregate-address后面加不加summary-only是两种完全不同的行为。不加的时候聚合路由和明细路由同时宣告出去——上游两条都收到转发时按最长匹配选明细聚合路由基本是个摆设只在你明细全部消失时才起作用。加了summary-only明细全部被抑制上游只看到聚合路由。很多文档到这就结束了但真正的坑在后面summary-only抑制的是对外宣告不是本地转发。你本机的BGP表和路由表里明细还在转发依然按明细走一切正常。但上游只看到汇总它把到整个/22的流量都往你这儿送然后你在本地按明细再分发出去。这个模型没问题前提是你的明细链路都是通的。问题出在明细链路的多样性上。如果10.1.2.0/24这条明细实际是走另一台边界设备出去的你在这台设备上做了summary-only上游的回程流量还是会全部涌到这台设备然后由它转发给另一台。多了一跳链路利用率也可能失衡。这就是我前面说的聚合破坏流量工程。解决办法是在做summary-only之前画一张图聚合前缀覆盖的每一条明细入向和出向分别走哪台设备、哪条链路。凡是路径不一致的要么不聚要么把它拆出来单独宣告。另外summary-only是有粒度的——它抑制的是这个聚合前缀范围内的所有明细。如果你只想抑制一部分、保留一部分那就得用suppress-map而不是summary-only。这一点后面说。3.2 as-set与原子聚合环路防护的代价这两个参数经常被当成加上就对了的保险其实它们改变的是路径属性会影响对端的选路结果。先讲原理。BGP防环靠AS_PATH一条路由如果AS_PATH里出现了自己的AS号就丢弃。明细路由聚合成一条之后原来每条明细的AS_PATH信息就丢了。如果这些明细来自不同的上游、带着不同的AS_PATH聚合路由该继承哪一条标准做法是如果多条明细的AS_PATH不一致聚合路由用AS_SET花括号包起来的无序AS集合来表示这条路由经过了这些AS中的任意一个。配置上加as-set就是让设备生成这条AS_SET。不加的话不同实现的处理有差异有的会直接不打AS信息、打上atomic-aggregate标记有的会选其中一条的AS_PATH。无论哪种风险是环路防护被削弱对端如果在AS_SET覆盖的范围内看到不带自己AS号的路由就可能收下形成环路。代价是什么AS_PATH长度是按跳数比较的AS_SET在很多实现里计为1跳但有些实现按元素个数计。这会直接影响对端的选路——本来你的路由路径长度有优势加上as-set之后路径变长可能被别的上游抢走流量。我遇到过加了as-set之后入向流量跑掉三成的情况查了半天才发现是路径长度排名变了。atomic-aggregate是个纯标记表示这条聚合路由丢失了部分明细信息。它不能防环只是告诉接收方别完全相信这条路由的AS_PATH。你如果配了as-set通常就不需要额外关注它如果不配as-set它会自动打上这时候要留个心眼某些对端策略看到这个标记会降低优先级甚至拒绝。我的实操建议很直接明细来自单一上游、AS_PATH一致可以不加as-set明细来自多个上游必须加as-set并且加完之后一定去对端确认选路结果有没有变化。别在本端show一下就算完事。参数作用不加的后果加的代价summary-only抑制聚合范围内全部明细明细与聚合同时宣告聚合形同虚设失去明细级的回程分流能力as-set用AS_SET记录明细的AS来源环路防护削弱可能被对端收下造成环路路径长度变化影响对端选路atomic-aggregate标记信息不完整部分实现自动打上可能被对端降权无配置代价但语义上等于承认信息缺失attribute-map给聚合路由设置属性聚合路由属性为默认值可能选路不理想配置复杂度上升需与现有策略协调suppress-map按条件抑制部分明细只能全抑制或全不抑制策略维护成本容易和过滤策略冲突advertise-map满足条件才生成聚合明细一撤聚合就消失多一层逻辑排障时需要同时看两个条件3.3 attribute-map、suppress-map、advertise-map精细化控制这三个map是把聚合从一刀切变成可控的关键但用法各有侧重别搞混。advertise-map决定聚合路由什么时候生成。只有匹配这个map的明细路由存在时聚合才生效。典型用法是你有一个/22的聚合前缀但里面只有两个/24是主力业务其他是备用。你配advertise-map只匹配主力/24这样主力在的时候聚合就宣告主力全撤了聚合也跟着撤避免用一个空壳汇总把流量引进来。这个参数在双活/主备场景里特别有用。suppress-map决定哪些明细被抑制。它比summary-only灵活的地方在于可以只抑制一部分。比如一个/22里有四个/24其中三个走本机、一个走对端设备你希望抑制走本机的那三个、保留走对端的那一个那就用suppress-map匹配前三者。配置上要注意一旦用了suppress-mapsummary-only就不能同时用两者语义冲突。attribute-map决定聚合路由带什么属性。聚合路由的origin默认是INCOMPLETEcommunity、local-preference、MED这些属性不会自动从明细继承不同实现有差异但不要指望它继承。如果你需要给聚合路由打上特定的community供对端做策略或者设置MED影响回程选路就得靠attribute-map。这里有个细节attribute-map设置的是聚合路由本身的属性不影响被抑制的明细。顺带说一句这三个map的匹配对象是明细路由不是聚合路由写策略的时候别把方向搞反了。我见过有人把匹配条件写成聚合前缀结果一个都匹配不上查了两小时。4. 实操过程从零配出一条可用的聚合路由4.1 实验环境与地址规划我习惯先在隔离环境里跑通再上生产这一步千万别省。实验环境不需要多复杂三台设备一台模拟上游AS 65100一台是被操作的边界设备AS 65001一台模拟下游接入AS 65200。地址规划如下设备角色接口地址作用上游192.0.2.1/30与边界设备互联模拟真实上游边界设备192.0.2.2/30与上游互联边界设备198.51.100.1/30与下游互联下游198.51.100.2/30模拟分支接入业务明细10.1.0.0/24 至 10.1.3.0/24四条待聚合的明细配置思路是下游把四条/24通过BGP宣告给边界设备边界设备在BGP进程里配一条aggregate-address 10.1.0.0/22并且加summary-only和as-set然后观察上游收到什么、边界本地的BGP表和路由表分别长什么样。这个三张表对照的习惯是我排障时最依赖的手段后面会反复用到。4.2 配置步骤与逐行解析配置本身不长但每一行都要知道它在干什么。下面用两种常见的命令行风格示意具体语法按你手上的设备调整。! 下游设备宣告四条明细 router bgp 65200 network 10.1.0.0 mask 255.255.255.0 network 10.1.1.0 mask 255.255.255.0 network 10.1.2.0 mask 255.255.255.0 network 10.1.3.0 mask 255.255.255.0! 边界设备配置聚合 router bgp 65001 aggregate-address 10.1.0.0 255.255.252.0 summary-only as-set如果设备支持CIDR写法等价的形式是aggregate-address 10.1.0.0/22 summary-only as-set。两种写法在功能上没有区别我一般用CIDR写法因为不容易把掩码写错——255.255.252.0这种点分掩码我见过写成255.255.255.0的那样就变成/24聚合结果一条明细都不匹配聚合路由根本不生成还不报错。接着给聚合路由打属性这一步是可选的但很实战route-map AGG-ATTR permit 10 set community 65001:100 set local-preference 200 set origin igp ! router bgp 65001 aggregate-address 10.1.0.0/22 summary-only as-set attribute-map AGG-ATTR这里解释三个动作。set community是把聚合路由打上标记方便对端做策略匹配也方便你自己在show输出里一眼认出这条路由是不是聚合来的。set local-preference设成本地有效值只在本地生效对外宣告时不会带出去所以这一步对本机选路有意义、对上游无影响——如果你的边界设备同时从多个邻居学到这个聚合前缀一般不会但实验环境可能本地优先级能保证选本机生成的这条。set origin igp是把聚合路由的origin从不完整改成IGP这个改动要谨慎origin影响BGP选路顺序IGP优于EGP优于INCOMPLETE改成IGP可能让这条路由在某些对端那里排名变高也可能被对端的策略拒绝。生产环境我一般不动origin保持INCOMPLETE除非有明确理由。4.3 验证五条命令确认结果符合预期配置敲完不等于生效。我按固定顺序跑五条命令每一步都对照预期出问题立刻能定位到哪一层。第一条看BGP表里聚合路由是否存在。show ip bgp 10.1.0.0/22预期看到这条路由的下一跳是本地origin是INCOMPLETE除非你改了AS_PATH里带有花括号的AS_SET形如{65200}路径末尾是你自己的AS号。如果这条命令没有输出说明聚合路由根本没生成先回去查明细在不在。第二条看明细是不是都被抑制了。show ip bgp 10.1.0.0/22 longer-prefixes预期看到四条/24明细每条前面有个标记表示suppressed常见是s并且都显示suppressed by 10.1.0.0/22之类的原因说明。如果某条明细没有s标记说明它没被抑制可能是它不在聚合范围内、或者被其他策略放行了。第三条看本机路由表确认转发不受影响。show ip route 10.1.0.0 255.255.252.0 longer-prefixes预期四条明细都在且都是BGP学来的有效路由下一跳指向下游。这一步很关键因为summary-only只影响宣告不影响本地转发如果这里看不到明细说明明细本身就没进路由表那聚合出来的东西就是空的。第四条看上游实际收到什么。show ip bgp neighbors 192.0.2.1 advertised-routes预期只看到一条10.1.0.0/22看不到任何/24。这是最终验证——本地配得再对上游没收到就是白干。如果这里还能看到明细八成是邻居的outbound策略把聚合路由也拦了或者summary-only没生效。第五条看上游侧学到的内容最好在上游设备上敲。show ip bgp 10.1.0.0/22 show ip bgp neighbors 192.0.2.2 routes预期上游只学到一条聚合路由AS_PATH里能看到AS_SET并且带atomic-aggregate标记如果没加as-set的话。这一步是双人复核我一般要求操作人和复核人分别在自己的终端上敲避免我以为你看了。4.4 抓包与邻居状态观察命令看的是设备自己的认知抓包看的是链路上真实发生了什么。有些问题只有抓包能看出来比如聚合路由的更新报文里AS_PATH到底带了什么、community有没有被剥离、更新是不是被拆成了多条。tcpdump -i eth0 -n -s0 tcp port 179 -w bgp_update.pcap抓完用分析工具打开找到10.1.0.0/22那条UPDATE重点看三个字段AS_PATH里是不是有AS_SET花括号、COMMUNITIES里有没有你设的标记、ORIGIN是什么值。这一步在跨域互联的对接阶段特别有用因为双方对属性的理解差异经常导致我发了你没收到或者收到了但没选上。另外一个容易忽略的点是更新报文的大小。BGP的UPDATE报文有4KB上限如果聚合前的明细带了大量community聚合后虽然条数少了但每条更长偶尔会触发消息分片。这不是聚合本身的问题但配完聚合后观察一下邻居的update消息计数能提前发现异常。5. 常见问题与排查实录5.1 配了聚合但邻居收不到的六种原因这个现象太常见了我按排查顺序列出来从最常见到最罕见。原因一明细根本不在BGP表里。聚合是条件生成的BGP表里没有落在范围内的明细聚合路由就不存在。注意不在BGP表和不在路由表是两回事如果明细是通过IGP学来的、没有重分发进BGP那BGP表里就是空的。检查方法很简单show ip bgp后看有没有/24明细。原因二明细存在但不是有效路由。明细在BGP表里但被标记为无效下一跳不可达、被惩罚、被入向策略拒绝这种情况下聚合路由通常也不会生成。查show ip bgp的明细条目看前面的有效性标记。原因三聚合掩码写错了。前面提过255.255.252.0写成255.255.255.0或者CIDR写成/23都会导致范围不匹配。这类错误设备不会报错因为语法是合法的只是逻辑上一条明细都匹配不到。原因四advertise-map条件不满足。如果你配了advertise-map而匹配条件里的前缀列表写错了、或者匹配的明细不存在聚合就不会生成。排查方法是用show route-map看匹配计数或者临时把advertise-map去掉验证。原因五明细在入方向就被过滤了。邻居的inbound策略把/24全拒了你本地BGP表里压根没有明细。这种情况下你会在邻居的show命令里看到明细在自己这边看不到方向很好判断。原因六邻居的outbound策略拦了聚合路由。这条最隐蔽因为本地一切都正常。某个前缀列表只放行了明细、没放行聚合前缀或者反掩码写错导致/22不被匹配。解决办法是在show advertised-routes里看如果没有聚合路由基本就是这条。5.2 黑洞与流量绕行聚合最常见的两个事故黑洞的成因有两种。第一种是前面说的洞——聚合前缀覆盖了不属于你的地址外部流量打到那些地址上你这边没有对应明细只能按默认路由走或者直接丢弃。第二种更隐蔽所有明细都撤销了但聚合路由因为某种原因还留着比如用静态汇总network的方式做的后面会讲外部还在往里送流量你这边一条明细都没有全部黑洞。第二种情况我在一次链路全断的事故里见过。当时下游整个机房的BGP会话都断了四条明细全部撤销但边界设备上配的那条null0静态汇总路由还在network还在宣告上游一直把流量送过来全砸在null0上。从监控上看链路是通的、BGP邻居是Established的但业务全挂。这个教训让我此后所有聚合方案里都加了一条聚合路由必须有对应的健康检查或者保底明细不能让它变成一条永远存在的空壳。流量绕行的成因是聚合破坏了入口多样性。原本A链路承载10.1.0.0/24和10.1.1.0/24B链路承载10.1.2.0/24和10.1.3.0/24两条链路各分担一半。聚合成10.1.0.0/22之后上游只看到一条汇总它按自己的选路逻辑全部走A链路进来然后你在本地把2.0和3.0的流量再转给B设备。结果是A链路入向拥塞、B链路入向空闲B设备还要多承担一次转发。这种问题在带宽吃紧的时候才会暴露平时看不出来。解决办法有两个一是不做全聚合保留一部分明细用于分流比如聚成两条/23分别走两条链路这样上游有两种选择虽然粒度粗了点但能保住基本的负载分担二是在上游侧配置基于community的本地优先级让上游对聚合路由做分流。第二种需要跟上游协商很多环境做不到。5.3 问题速查表现象最可能的原因快速验证方法处理方式配置了聚合邻居收不到明细不在BGP表或无效show ip bgp 明细前缀检查明细来源与有效性聚合路由存在但明细仍在宣告summary-only未生效或语法错show ip bgp neighbors advertised-routes核对命令与outbound策略部分明细未抑制不在聚合范围内show ip bgp 聚合前缀 longer-prefixes重新计算聚合前缀对端收到的AS_PATH异常未配as-set导致信息丢失对端show ip bgp明细加as-set并复核选路加as-set后入向流量减少路径长度变化影响选路对比加前加后的对端选路评估是否必须加或用attribute-map补偿业务访问慢但链路通聚合后回程路径单一化对比各明细的原路径拆分聚合或协商分流策略明细全撤后仍收到流量静态汇总路由未撤销show ip route 聚合前缀加联动机制或健康检查上游拒绝聚合前缀前缀长度过滤策略与对端确认策略调整聚合长度或申请放行6. 影响范围与上线节奏聚合不是一条命令的事6.1 对路由表、内存、收敛的量化影响说聚合能优化路由表谁都会说但优化多少得有数。我拿一次真实的改造做过对比某边界设备原来对外宣告一百六十三条明细聚合成二十一条汇总后上游侧的路由表条目减少一百四十二条BGP进程内存下降约百分之一点八CPU在收敛期间模拟明细抖动的峰值从四成降到一成五。内存下降比例看起来不大是因为全表占了绝大多数你自己宣告的那部分只是零头。所以如果你的动机是省内存聚合的收益其实有限如果你的动机是减少收敛时的路由翻动和应对上游的前缀数限制收益就非常明显。这个区别很重要决定了你值不值得为聚合承担那些风险。收敛方面的影响更值得关注。明细被聚合后单条明细的抖动被吸收上游感知不到这是好事。但如果所有明细同时撤销聚合路由也会撤销上游看到的是一条大前缀消失影响面比原来四条小前缀消失大四倍。这就是聚合的放大器效应——它同时放大了稳定性和故障影响范围。所以聚合必须配合明细级的监控不能因为上游看不到明细就以为本地也不用管。还有一个常被忽略的影响是日志和监控。聚合后你在上游侧的所有告警、流量分析、异常检测都是基于汇总前缀的粒度变粗。原来能定位到某条/24流量异常现在只能看到这个/22总量异常。如果业务方依赖细粒度流量数据做容量规划聚合会让他们失去依据。这一条我在做方案评审时一定会提因为它影响的是别的团队的日常工作不是你自己能决定的。6.2 灰度上线与回滚方案聚合这种改动我从来不一次性全量上。实操节奏是这样的第一步在实验环境验证全部参数组合包括异常场景明细撤销、邻居断开、策略变更。第二步选一个影响面最小的分支做试点观察至少一个完整业务周期重点看回程路径和链路利用率。第三步试点稳定后按批次推进每批之间留出观察窗口同时准备好回滚脚本。回滚脚本要提前写好不能等出事再想。内容很简单删掉aggregate-address那一行然后确认明细重新出现在邻居的advertised-routes里。注意删聚合的时候如果用了summary-only明细会自动恢复宣告但有些实现需要手动触发一次邻居重置或者等待更新周期这个过程可能几十秒到几分钟业务会有一段上游看不到任何路由的窗口。我的做法是先在低峰期做并且提前通知上游的值班人员。阶段动作观察指标回滚触发条件实验验证全参数组合测试聚合路由生成、明细抑制、AS_PATH正确任一不符预期单点试点一个分支聚合上线入向流量分布、回程路径、链路利用率回程路径变化超过预期或单链路超阈值分批推进按站点批次聚合上游前缀数、收敛时间、告警量出现黑洞或业务投诉稳定运行监控与容量复核明细级流量数据完整性业务方反馈数据不可用最后分享一个我一直用的习惯每次做聚合之前我会把聚合前后的三张表本机BGP表、本机路由表、上游学到的表各存一份快照存在设备的本地存储里文件名带上时间。真出问题时这两份快照的差异就是最直接的证据链比回忆当时配了什么靠谱一百倍。这个习惯帮我省过至少两次通宵也让我在复盘的时候能拿出实打实的数据而不是感觉是聚合引起的。