链路聚合这个词，做过机房的人都不陌生。但凡机柜里两台设备之间连了两根以上的网线，总有人会问一句"这俩口聚合了没"。可真到配置的时候，很多人只是把几个物理口往一个逻辑口里一塞，看到状态 up 就收工，等到业务真正跑起来才发现带宽没涨、单条大流量还是卡在一个口上、某天拔掉一根线整个业务全断。这篇文章聊的就是路由器和交换机之间做链路聚合这件事——它是什么、为什么这么设计、路由器侧和交换机侧到底差在哪、哈希怎么选、配完怎么验、起不来的时候按什么顺序排查。适合刚接手网络运维的同行，也适合做了几年但一直把聚合当成"点两下就完事"的工程师，里面有些细节是文档里不会写、只有实际拉过线流过量的才知道的。
1. 单链路撑不住的时候，聚合到底叠了什么
1.1 一条千兆链路的真实吞吐上限
先说个很多人没细算过的账。一条标称千兆的链路，理论速率是 1Gbps，双向全双工意味着一收一发各自独立，但这不等于你能同时跑满两个 1G。实际业务里，TCP 的有效吞吐要扣掉帧头、IP 头、TCP 头的开销，再扣掉交换机内部的转发延迟和窗口协商的影响，单条千兆链路跑个 940Mbps 左右已经算不错。如果是小包场景，比如监控信令、金融行情推送，包长只有一百多字节，那有效吞吐可能掉到两三百兆，因为每个包都要走一遍完整的转发流程，包的间隔和校验开销占比太高。
这就带来一个很现实的问题：当两台核心设备之间的南北向流量开始逼近单链路极限时，加带宽的方式只有两种——换更高速率的端口，或者把多条链路捆成一条逻辑链路。前者要换板卡、换光模块、甚至换整机，成本和停机窗口都摆在那；后者只要设备上有空闲端口，插上线配几下就能用。链路聚合之所以在企业网里普及，本质上是因为它用"横向加端口"的方式绕开了"纵向换速率"的昂贵路径。
但这里必须先纠正一个最常见的误解：聚合后的带宽是多个成员口的叠加，这个叠加是"总量"意义上的，不是"单条流量"意义上的。四个千兆口聚合成一个 4G 的逻辑口，意味着这台设备整体往对端能推送 4G 的流量，但任何一条单独的五元组会话，永远只会在其中一个成员口上跑，最多也就 1G。这一点后面讲哈希的时候会展开，先记住结论。
1.2 带宽叠加之外，冗余才是更硬的收益
很多人做聚合是冲着带宽去的，但真正让运维夜里睡得着觉的是冗余。单根网线连着两台设备，这根线被机柜门夹了、光模块老化接触不良了、或者施工的时候被人踢掉了，链路直接 down，业务瞬间中断，等你去机房找线换线，少说十几分钟。做了聚合之后，成员口之间互为备份，任何一根断掉，流量在秒级内重新分配到剩下的成员口上，业务最多丢几个包。
这个切换速度取决于聚合的协商方式。动态聚合靠协议报文维持邻居关系，成员口故障时协议能快速感知并把该口从转发集合里摘掉，通常在一秒以内；静态聚合没有协议报文，靠物理层的 link 状态来判定，链路 down 了也能摘，但如果是对端设备的问题而本地物理层还是 up 的，静态聚合就感知不到了，会把流量继续往一个黑洞里发。这就是为什么我一直建议生产环境用动态聚合，多出来的那点协议开销换来的是故障感知能力。
冗余还有一层：成员口不必都在同一块板卡上。设备内部的背板和交换芯片是有转发能力上限的，如果四个成员口全插在同一块板卡上，板卡本身挂了，聚合口一样全断。把成员口分散到不同的板卡、不同的芯片组上，才是真正意义上的设备内冗余。当然这有个前提——设备得支持跨板卡聚合，有些低端设备是明确限制成员口必须同板卡同芯片的，配之前查一下规格书，别想当然。
1.3 哪些场景压根不该做聚合
聚合不是万能的，有些场景硬上反而添乱。第一种是两端设备之间的流量本来就很小，比如一台接入交换机上联到汇聚，平时峰值也就几十兆，这种做聚合纯属浪费端口，两个口捆一起除了增加配置复杂度没有别的收益，还不如留一个口做冷备。第二种是跨设备的链路，比如一台路由器分别接两台不同的交换机，想让这两条链路聚合——不行，标准聚合要求所有成员口的对端是同一个聚合实体，跨设备要么用堆叠把两台交换机虚拟成一台，要么用多机箱聚合这类扩展方案，普通聚合做不到。
第三种更要小心：链路两端如果中间经过了传输设备、光端机、或者运营商线路，聚合的协议报文可能被中间设备丢弃或者改写，导致协商不上。这种情况下要么改用静态聚合，要么干脆放弃聚合改用路由层面的等价多路径。我见过一个场景，两个机房之间拉了两条专线想做聚合，结果中间的光传输设备把 LACP 报文当未知组播过滤掉了，折腾了一整天才定位到是中间设备的问题。
2. LACP 的报文交互：聚合口是怎么"谈"成的
2.1 LACPDU 里到底装了什么
动态聚合跑的协议叫 LACP，它靠一种叫 LACPDU 的慢协议报文来维持邻居关系，目的 MAC 是一组固定的组播地址，报文每隔一段时间发一次，默认快模式 1 秒一发、慢模式 30 秒一发。这个报文里带着几个关键字段，理解它们才能理解聚合的选举逻辑。
第一个是系统优先级，标识本端设备的优先级，值越小越优先。两端协商的时候会选出一个"主动端"，主动端的系统优先级和系统 MAC 组合更小的那一方说了算，由它来决定哪些端口进入活动状态。第二个是端口优先级，同一个聚合组里每个成员口都有自己的优先级，值越小越优先被选为活动口。第三个是操作键（Key），这是个很关键的字段，只有 Key 值相同的端口才会被归到同一个聚合组里，两端 Key 不匹配就会一直协商不上。
还有一个端口状态字段，里面用几个比特位表示这个口是否处于活动状态、是否处于聚合中、是否处于同步状态。同步位的意思是这个口已经准备好转发流量了，两端都置位才算真正 up。很多"聚合口起来了但不通"的问题，本质就是同步位没置上——物理层 up、协议也在收发，但状态机卡在某个中间态。
2.2 主动模式与被动模式的组合矩阵
LACP 有主动和被动两种工作模式。主动模式会无条件下发 LACPDU，被动模式只有在收到对端的 LACPDU 之后才回发。这就形成了一个组合矩阵，两端的模式搭配决定了能不能协商成功：
| 本端模式 | 对端模式 | 协商结果 |
|---|---|---|
| 主动 | 主动 | 正常协商，双方都发报文 |
| 主动 | 被动 | 正常协商，被动方收到后回发 |
| 被动 | 被动 | 协商失败，双方都不主动发 |
| 静态 | 静态 | 不走协议，靠配置强制捆绑 |
| 动态 | 静态 | 通常失败，一端发报文一端不理 |
最后一行是实际运维里踩得最多的坑。一端配了动态聚合，另一端图省事配了静态，结果就是动态那端一直发 LACPDU 收不到回应，端口状态卡在"未同步"，聚合口起不来。这种问题排查起来很折磨人，因为两端的配置单看都没错，就是配不到一块去。我的习惯是配置前先跟对端确认清楚用哪种模式，配置完立刻在两端各查一次协议邻居状态，两边都能看到对方才算过关。
2.3 活动端口与备份端口的选举顺序
当成员口的数量超过了聚合组允许的最大活动端口数，或者两端能力不对等的时候，就会涉及活动口和备份口的选举。选举依据是一个多级比较：先比系统优先级，再比系统 MAC，然后比端口优先级，最后比端口号。整个比较过程是确定性的，两端算出来的结果一致，所以不会出现双方各选各的导致混乱。
这里有个实际影响：如果你希望某个高速端口优先承载流量，或者希望在成员口数量受限时保证特定端口是活动口，就得手动调整端口优先级。默认优先级通常是 32768，改成一个更小的值就能把它顶到前面去。反过来，如果你想临时把某个口从聚合里摘出来做维护，又不想删配置，把这个口的优先级调到最大，它就会自动退到备份状态，流量迁走，维护完再调回来。这招在做在线割接的时候特别好用，比重启端口温和得多。
2.4 静态聚合与动态聚合的取舍
静态聚合也叫手工模式，两端强制把几个口捆成一个逻辑口，不发协议报文，不协商，配了什么就是什么。它的优点是配置简单、不依赖协议、对中间传输设备友好；缺点是没有任何故障感知能力，一端的问题另一端看不见，而且容易出现"一端认为聚合成功、另一端根本没配"的单通情况。
动态聚合靠协议协商，能感知对端状态，成员口故障时切换更干脆，还能防止配置不对称带来的环路风险。代价是需要两端都支持并且模式匹配，报文可能被中间设备干扰。
我的实际选择标准是这样的：两端设备直连、都支持 LACP 的，一律用动态；中间隔了传输设备或者对端是老设备不确定支持情况的，用静态，但必须人工确认两端配置完全对称，并且在上线后做断链测试。断链测试这一步千万别省，静态聚合最怕的就是你以为有冗余其实没有。
3. 路由器侧做聚合和交换机的差别在哪
3.1 三层聚合口：逻辑口上要配 IP
交换机上做聚合，多数场景是二层聚合，聚合口是个二层逻辑口，往里加 VLAN、做 Trunk，对端也是交换机。路由器上做聚合，情况就不一样了——路由器的端口天生是三层口，聚合之后形成的是一个三层聚合口，你需要在这个逻辑口上直接配 IP 地址，把它当成一个普通的三层接口来用。
这个差异带来的第一个影响是：成员口上不能再配 IP。物理口加入聚合组之后，它的三层属性被聚合口接管了，你在成员口上配 IP 会报错或者被忽略。有些人习惯先在物理口上配好 IP 再聚合，结果发现 IP 全丢了，还以为是配置出错。正确顺序是先建聚合口、配 IP、再把物理口加进去。
第二个影响是路由协议的行为。聚合口作为一个三层接口参与路由计算，它的 up/down 状态直接影响路由表。如果聚合口的成员口全部 down，聚合口跟着 down，这条路由失效，流量切走；只要还有一个成员口活着，聚合口就保持 up。这个特性对跑 OSPF 或者 BGP 的链路特别友好，不会因为单根线断就导致邻居关系震荡。但也带来一个隐患：如果聚合口只剩一个成员口在撑着，带宽已经掉到四分之一了，路由协议是感知不到的，它还认为这条路径是满带宽，继续往这边压流量。所以做聚合的链路最好配上流量监控，成员口数量掉到阈值以下就告警。
3.2 二层聚合与三层聚合的选型判断
路由器上到底该做二层聚合还是三层聚合，取决于这条链路承载什么。如果两台路由器之间跑的是三层互联，各配一个互联 IP，跑 OSPF 或者静态路由，那做三层聚合最直接，聚合口上配 IP，两边做直连。如果路由器下面是接交换机，交换机上划分了多个 VLAN 需要透传上来，路由器做单臂路由或者子接口，那聚合口就得是二层的，然后在聚合口上起子接口对应各个 VLAN。
这里有个细节容易忽略：二层聚合口上起子接口的时候，子接口的编号和封装 VLAN 要跟对端严格对应，而且聚合口的 MTU 要预留出 VLAN 标签的长度。有些场景下大包不通、小包正常，查半天是 MTU 没算对——物理口 MTU 1500，加了 4 字节 VLAN 标签就变成 1504，如果聚合口和子接口的 MTU 没协调好，超过 1496 的包就被丢了。
还有一种混合场景：聚合口先做二层，划进某个 VLAN，再在这个 VLAN 上配一个 VLAN 接口（SVI）作为三层网关。这种方式在路由器上也能做，好处是同一个聚合口既能透传其他 VLAN 给下游，又能自己作为一个网关地址存在，灵活性比纯三层聚合高。坏处是多了一层间接，排错的时候要同时看二层转发和三层路由两张表。
3.3 路由器侧聚合的硬件限制比交换机多
这一点是很多人没意识到的。交换机的交换芯片天生就是为多端口并行转发设计的，做聚合是它的本行，支持度和灵活性都高。路由器的转发面更强调单流性能和业务处理，聚合的支持度参差不齐，尤其是中低端路由器，经常有各种各样的限制。
常见的限制包括：成员口必须属于同一个端口组、必须同速率同双工、不能跨越不同的业务板卡、聚合组数量有上限、某些业务特性（比如 NAT、策略路由、流量整形）在聚合口上不支持或者性能打折。这些限制在配置手册的角落里写着，不仔细看根本发现不了，配的时候不报错，跑起来才发现某个功能不生效。
我的建议是配置前先把设备的规格说明翻一遍，重点看三处：最大聚合组数、每组最大成员数、成员口是否有位置约束。有些设备的端口是分组的，比如前四个口一组、后四个口一组，跨组聚合直接不支持。如果不提前确认，线都插好了才发现配不上，那场面很尴尬。
4. 哈希算法决定了你只能跑到几成功力
4.1 流量是怎么被分配到成员口上的
聚合口把流量往成员口上分发，靠的是哈希。设备会提取报文里的某些字段，算一个哈希值，用这个值对成员口数量取模，落到哪个口就走哪个口。这个过程是逐包进行的，同一个流的包因为关键字段相同，算出来的哈希值也相同，所以会被稳定地送到同一个成员口上——这样才不会导致乱序。
提取哪些字段是由哈希策略决定的，常见的选项有：仅源 MAC、仅目的 MAC、源加目的 MAC、源 IP 加目的 IP、源 IP 加目的 IP 加四层端口。不同厂商的默认策略不一样，有的默认只算 MAC，有的默认算 IP，有些设备还提供了基于流的自适应模式。这个策略选得对不对，直接决定了聚合链路能不能被用满。
4.2 单流跑不满是常态，别急着怀疑配置
举个具体的例子。四根千兆线做聚合，理论总量 4G。如果你的业务是备份系统往远端传一个大文件，这就是一条 TCP 流，源 IP、目的 IP、源端口、目的端口全固定，哈希值固定，永远走同一个成员口。不管你聚合了几个口，这条流最多 1G。这时候去看总流量，发现只有 1G，可能会误以为是聚合没生效，其实聚合生效了，只是这条流用不上。
反过来，如果是办公网里几百个终端同时访问外网，每条流的源 IP 和源端口都不同，哈希值分散，流量就能均匀铺到四个口上，总量能逼近 4G。所以判断聚合有没有效果，不能看单条流，要看聚合口的总体流量和各个成员口的分布。
这里还有个容易踩的坑：哈希策略要两端一致，至少不能互相冲突。如果一端按源 IP 哈希、另一端按目的 IP 哈希，虽然各自都能分发，但在非对称流量模型下可能出现某条流去程走 A 口、回程走 B 口的情况，只要两端都能正常转发就没问题，但如果中间有状态防火墙，会话表可能就对不上了。稳妥的做法是两端配置成同一套哈希因子。
4.3 哈希极化：为什么分布看起来很不均匀
有时候配置明明没问题，去看各成员口的流量，发现一个口跑到 90%、其他三个口只有 10%。这种情况叫哈希极化，本质是流量特征太单一，哈希算法没法把它们打散。
典型的触发场景是：虚拟机环境里少数几台大流量虚机通过同一台物理主机出网，源 MAC 只有那么几个；或者所有流量都经过一个 NAT 设备转换，出去之后源 IP 全变成一个；又或者做的是纯二层转发，可用的哈希字段只有 MAC，而 MAC 地址的分布恰好集中在某几个值上。这些情况下，改哈希策略能缓解，比如从"仅源 MAC"改成"源 MAC 加目的 MAC"，或者干脆改成基于 IP 的哈希，让三层的多样性参与进来。
还有一种更隐蔽的极化：某些设备的哈希算法实现得不够好，对特定前缀的地址计算出来的结果总是落在少数几个桶里。这不是配置能解决的，只能通过升级固件或者换哈希策略绕开。我在一个项目里遇到过，四个成员口里有两个常年闲置，把哈希从 MAC 改成 IP 之后分布立刻均匀了，说明问题就出在 MAC 哈希的实现上。
4.4 验证分流效果的具体方法
配完聚合别急着收工，一定要验证分流。方法很直接：在各成员口上查收发字节计数，间隔一段时间（比如 30 秒）各查一次，做差算出每个口的增量，看增量是不是大致均匀。如果某个口增量为零，说明流量压根没分过去，要么哈希策略有问题，要么这个口的状态不对。
更进一步可以打流测试。用两台终端接在聚合链路两端，跑多组并发的 TCP 连接（比如用多个并行的文件传输任务），看总吞吐能不能接近聚合带宽。单条流测试是没有意义的，只能验证 1G 的上限。有条件的可以用专业的打流仪表，构造不同五元组分布的流量，逐组验证分发效果，这是最靠谱的办法。
5. 配置落地：从物理口到逻辑口的完整步骤
5.1 配置前的规划清单
动手之前先把这几件事定下来，能省掉后面大量的返工：
- 成员口选哪几个：优先选空闲端口，确认速率和双工一致，尽量分散在不同板卡上。
- 聚合组编号：两端不必相同，但为了可维护性建议统一，比如都用 10。
- 聚合模式：动态还是静态，两端必须一致。
- 哈希策略：按业务流量特征选，两端一致。
- 聚合口的地址规划：三层聚合配什么 IP，二层聚合划哪个 VLAN。
- MTU：尤其是二层聚合带 VLAN 标签的场景，要预留标签长度。
这份清单看着啰嗦，但每一条对应一个实际踩过的坑。尤其是速率双工这一条，光纤两端一端自协商一端强制千兆，看起来都是 up，实际协商成了一千兆半双工或者反复翻转，聚合根本稳不住。
5.2 交换机侧的配置逻辑
交换机侧通常是二层聚合，配置思路是先建聚合口、再往里加成员口。命令行的措辞各家不同，但要素就那几个：
# 创建聚合组，指定工作模式为动态 interface Bridge-Aggregation 10 port link-type trunk port trunk permit vlan 10 20 30 link-aggregation mode dynamic # 把物理口加入聚合组 interface GigabitEthernet 1/0/1 port link-aggregation group 10 interface GigabitEthernet 1/0/2 port link-aggregation group 10关键点在于：成员口加入聚合组之后，成员口上原有的 VLAN 配置会被聚合口的配置覆盖。所以要先配聚合口的 VLAN 属性，再加成员口，顺序反了会发现 VLAN 配不上。另外有一些设备在成员口加入聚合组之后会提示"该口配置将被清除"，一旦确认，原来配的生成树、端口安全、限速全都归零，这一点要提前告知相关方。
5.3 路由器侧的配置逻辑
路由器侧做三层聚合，逻辑是先在聚合口上配 IP，再把物理口塞进去：
# 创建三层聚合口并配地址 interface Eth-Trunk 10 undo portswitch ip address 10.10.10.1 255.255.255.252 mode lacp-static # 物理口加入 interface GigabitEthernet 0/0/1 eth-trunk 10 interface GigabitEthernet 0/0/2 eth-trunk 10注意undo portswitch这个动作，它把聚合口从二层模式切换到三层模式，不同设备的命令不一样，有的叫no switchport，有的叫路由模式使能。漏了这一步，聚合口会当成二层口处理，IP 配不上。配完之后要确认聚合口的状态是 up，并且在路由表里能看到这条直连网段。
5.4 上线验证的三步走
配完不能只看聚合口 up 就完事，走完这三步才算真正通了：
第一步看协议邻居。两端各查一次 LACP 邻居信息，确认能看到对方的系统 ID，确认成员口的同步状态是已完成。如果一端能看到邻居、另一端看不到，说明是单向协商，多半是模式不匹配或者中间链路有问题。
第二步看成员口状态。每个成员口应该是"选中"状态，如果有口被标成"未选中"或"备份"，要查清楚原因——可能是端口优先级问题，也可能是两端能力不对等。
第三步做业务验证。从上游 ping 下游的地址，ping 大包（比如 1500 字节不分片），再用业务流量实际跑一遍。有条件的话拔掉一根成员线，看业务是否中断、切换需要多久、恢复后流量是否重新均衡。这个拔线测试是验证冗余是否真的有效的唯一办法，别省略。
6. 聚合口起不来的排查链路
6.1 现象分层：从"端口被踢"到"能 up 但不通"
聚合出问题，现象大概分三类。第一类是成员口压根加不进聚合组，配置时报错或者加进去立刻被踢出；第二类是聚合口起不来，逻辑口状态一直是 down；第三类是聚合口 up 了，但业务不通或者时通时断。这三类的排查方向完全不同，先归类再动手，能少走很多弯路。
第一类多半是配置层面的硬性限制：成员口速率不一致、有的口是光口有的是电口、跨了不支持的板卡、聚合组数量满了、端口被别的特性占用（比如已经划进了某个堆叠或者被镜像占用）。这类问题一般有明确报错信息，照着提示查就行。
第二类是协议协商层面：模式不匹配、Key 不一致、一端配了一端没配、中间设备丢了协议报文。这类问题最需要的是在两端同时看协议状态，单看一头永远看不出问题。
第三类是转发层面的问题，最难查，因为状态全是 up，就是不干活。往下看几节具体拆。
6.2 逐层排查的完整顺序
我习惯按下面的顺序往下走，从底层往上层，哪一层断了就停在哪一层：
物理层：光模块是否匹配，收发功率是否正常，电口的速率双工是否一致。光模块这一项特别容易忽略，一端是单模一端是多模，或者波长不匹配，端口能 up 但误码率极高，聚合时好时坏。查收发光功率是最快的手段。
聚合协商层：模式是否匹配、Key 值是否一致、系统优先级有没有异常。这里用一个技巧：把两端的状态信息都拉出来并排看，重点对比活动端口数、同步状态、邻居的系统 ID。如果一端认为有 4 个活动口、另一端认为只有 2 个，那就是双方的 Key 或者优先级配置有差异。
二层转发层：生成树是否把聚合口某个成员口阻塞了。有些设备的生成树默认会对聚合口做计算，如果配置不当，可能把整个聚合口或者部分成员口 block 掉。确认聚合口在生成树里是转发状态。
三层路由层：IP 是否配在同一网段、ARP 是否学到、路由是否指向聚合口。三层聚合口 up 但不通，很多时候是 ARP 学不到对端，原因可能是对端配了端口隔离、或者 MTU 不一致导致 ARP 报文被丢。
6.3 单通问题：去程通回程断
单通是聚合里比较典型的一类故障。表现是从 A 点 ping 不通 B 点，但在 A 点能 arp 到 B 点，或者在 B 点能看到 A 点的流量进来，回程却没有。这种现象通常指向几个原因：
一是两端哈希策略导致会话不对称，去程走了某个成员口、回程走了另一个，虽然理论上不影响转发，但如果中间有状态设备就会出问题。二是某一端的成员口状态异常，比如一端认为四个口都是活动口，往四个口都发流量，另一端只有两个口是活动口，另外两个口的流量直接被丢弃。三是静态聚合配置不对称，一端聚合了四个口、另一端只聚合了两个，多出来的两个口上的流量全成孤儿。
排查单通的利器是抓包。在聚合口上抓，看请求和响应是否都在、源目地址是否正确。如果发现请求有响应无，沿着路径逐跳抓，很快能定位到哪一跳开始丢。
6.4 跨板卡与跨芯片的坑
前面提过成员口尽量分散到不同板卡，但这件事本身也有坑。有些设备的跨板卡聚合是靠内部堆叠线或者交换网实现的，跨板卡的成员口之间转发会增加一跳内部转发，延迟略高、带宽可能受内部链路限制。更麻烦的是，某些设备对跨板卡聚合的哈希支持不完整，跨板卡的那几个口分流不均匀，流量全压在一个口上。
还有一种情况是设备内部有多个转发芯片，每个芯片只管自己下面那几个端口。跨芯片聚合的时候，从芯片 A 下的口进来的流量，要转发到芯片 B 下的成员口出去，需要经过内部互联，这个互联的带宽可能成为瓶颈，导致聚合总量上不去。这个瓶颈在配置上看不出来，只有实际打流才能发现。
判断方法很简单：把成员口全放在同一块板卡上测一次，再分散到不同板卡测一次，对比总吞吐。如果跨板卡之后吞吐反而下降，就说明内部互联是瓶颈，这时候要么接受现状，要么调整成员口分布。
7. 几个容易忽略的边界条件
7.1 成员口数量不是越多越好
有人觉得聚合口成员越多带宽越大，其实超过一定数量之后边际收益急剧下降。首先是哈希分布的均匀性，成员口越多，每个口分到的流量越少，单口利用率下降，但总带宽并没有线性增长——因为哈希碰撞的概率也在增加。其次是故障影响面，成员口多了，任何一根线出问题都要重新哈希，已经在传输的流会短暂中断，成员越多切换时的抖动越明显。第三是配置复杂度，八个口的聚合组，排查问题时要看的日志量是四个口的两倍。
实际经验是，企业网里四口聚合已经很够用，八口以上的聚合除非是数据中心核心互联或者大流量出口，否则没必要。与其堆成员口数量，不如把单口速率提上去，两个万兆聚合往往比八个千兆聚合更省事、更稳定、故障域更小。
7.2 升级和设备重启时的抖动
聚合链路在做设备升级、板卡重启、配置下发的时候会抖动。动态聚合因为要重新协商，恢复时间通常在几秒到几十秒；静态聚合恢复快一些，但恢复过程中可能出现短暂的环路或者黑洞。
降低影响的办法是把聚合成员分散到不同的设备上——如果两端都是堆叠或者虚拟化集群，让成员口分别落在不同的物理机框上，这样升级一台另一台还能撑住。如果做不到，那就把升级安排在业务低峰，并且在升级前先手动把流量导到备用路径（如果有的话）。
还有一点：某些设备在重启后聚合口的配置恢复有顺序依赖，聚合口先起来、成员口后起来，中间有个短暂的窗口聚合口是 down 的。如果这个聚合口承载着路由协议，会导致邻居重建、路由震荡。可以在聚合口上配延迟 up，等成员口都就绪了再启用逻辑口，这个小配置能省掉不少告警。
7.3 与生成树、堆叠、网关冗余的配合
聚合不是孤立存在的，它要和现网的其他机制配合。二层聚合口在生成树里会被当成一个逻辑端口参与计算，两端都做聚合的时候，生成树看到的是两个逻辑口之间的一条链路，正常情况下是转发，不会阻塞。但如果一端聚合、另一端没聚合，生成树就会把多余的链路 block 掉，形成"配了聚合但只有一条线在跑"的假象。这也是为什么聚合必须两端对称配置。
堆叠场景下，跨成员设备的聚合（也就是常说的跨设备链路聚合）能让一台设备故障时链路不断，这个能力对核心层很有价值，但它对两端的设备型号和软件版本有要求，不是所有设备都支持。配置前确认两端的能力矩阵，别想当然。
网关冗余协议和聚合的关系在于：如果聚合口承载的是网关地址所在的接口，聚合口的 up/down 会触发网关角色切换。这时候要确认切换时间和聚合的收敛时间匹配，否则可能出现主备都认为自己是主、或者都认为自己是备的短暂混乱。
7.4 监控指标怎么设才有意义
聚合链路上线之后，至少要监控四个指标：聚合口的总流量、各成员口的流量分布、成员口的 up/down 状态变化、以及成员口的误码和丢弃计数。
第一个指标看总量趋势，判断带宽是否够用。第二个看分布，判断哈希是否极化，如果某个口长期低于平均值的一半，就要考虑调整哈希策略。第三个看状态变化，成员口频繁 up/down 通常意味着光模块老化或者线缆接触不良，这种间歇性故障比彻底断掉更折磨人。第四个看底层质量，误码计数持续增长说明物理层有问题，哪怕端口还是 up 的，实际转发已经在丢包了。
这四个指标里，我觉得最容易被忽略的是第四个。端口 up 不等于链路健康，误码率高的时候聚合口照样 up，但业务侧表现为时快时慢、偶尔丢包，非常难定位。养成定期看误码计数的习惯，能在故障扩大之前发现问题。
最后分享一个我在实际配置里养成的小习惯：每次配完聚合，把两端的完整配置、协议状态、成员口计数各存一份快照，归档到变更记录里。下次出问题的时候，拿现在的状态和当时的快照一对比，差异立刻就出来了。这个动作花不了两分钟，但省下的排查时间往往是以小时计的。
