企业官网建设流程全解析

1. 先把需求想清楚：链路聚合到底在解决什么问题

我见过太多机房里的“两根网线插上去就算聚合”的操作，最后不是带宽没涨，就是环路把整层楼打瘫。链路聚合（Link Aggregation，标准里叫 IEEE 802.3ad，后来并入 802.1AX，各厂商叫法不同，有叫端口聚合、链路捆绑、Eth-Trunk、port-channel、bond 的）本质上是把多条物理链路捆成一条逻辑链路，让上层协议只看见一个接口。它能干三件事：把带宽叠加、把单链路故障的切换时间压到毫秒级、把原来被生成树阻塞掉的备用链路利用起来。适合谁看？手里有企业级交换机或路由器、需要做服务器双上行、核心与接入互联、或者路由器旁挂做三层互联的网络运维和集成人员。如果你手上只有家用小路由器，那几个 LAN 口是做不了标准聚合的，别在这上面浪费时间，直接看后面第 2 章的选型判断就行。

我先说一个最容易被忽略的前提：链路聚合不是“插两根线带宽就翻倍”。它是一个逻辑接口，流量进这个逻辑口之后，设备会按某种哈希规则挑一条成员链路发出去。也就是说，只有多条不同的“流”同时跑，才可能把总带宽吃满；单个 TCP 连接再怎么跑，也只能压在一条物理链路上。这个认知不建立起来，后面所有的配置和压测都会跑偏——你会以为配错了，其实是原理就这样。

1.1 三个真实需求场景，决定了你该怎么配

第一种场景是服务器双上行到接入交换机。服务器两块网卡做 bonding，交换机侧做聚合。这种场景最看重的是冗余和可维护性，带宽反而是次要的，因为大部分业务服务器的出口流量也就几百兆。这里的关键是两端模式必须对得上：服务器侧做动态 LACP，交换机侧就不能配静态聚合，否则一端发 LACPDU、一端不理，容易出现一端认为链路可用、另一端只启用一条的尴尬局面。

第二种场景是交换机与交换机之间的骨干互联。这是最典型的聚合场景，也是最容易踩坑的地方。两台设备之间四根千兆捆成四千兆，听起来很美好，但当你的业务是备份、虚拟机迁移、大文件传输这类长连接业务时，单流还是卡在 1G。这时候要么调整哈希算法让更多流分散，要么老老实实上 10G 口。我在一个备份项目里就遇到过这种情况：四条链路聚合做完了，备份速度纹丝不动，最后查出来是备份软件单线程传输，哈希到同一条链路，四条链路里三条闲着。

第三种场景是路由器与交换机之间的三层互联。这个场景比较特殊，因为很多路由器的聚合能力和交换机不一样。企业级路由器通常支持三层聚合口（在聚合口上直接配 IP），也支持在聚合口上做子接口终结 VLAN；但有些中低端路由器只支持二层聚合，或者根本不支持 LACP。所以做方案的时候，第一件事不是画拓扑，而是翻两台设备的数据手册，确认“支持几个聚合组”“每个聚合组最多几个成员”“支持静态还是动态”“支持三层聚合口吗”。这四个问题问清楚，能省掉后面一大半返工。

1.2 为什么不直接换成万兆，而要用聚合

这是个很现实的取舍问题，我在方案评审上被问过无数次。结论是：看你的瓶颈是“单流”还是“总流量”。如果业务是单一大流，比如一台机器往另一台机器传 500G 的镜像，那聚合帮不了你，直接换万兆光口和万兆网卡更干脆，因为单流受限于哈希算法，永远只走一条路。如果业务是大量并发小流，比如 Web 服务、虚拟化集群、办公网汇聚，那聚合的性价比就非常高——你不需要换光模块、不需要换交换机板卡，用现有端口就能把上行带宽从 1G 提到 4G 甚至 8G。

还有一层成本账要算：聚合占用的是端口数量。四根千兆聚合，交换机上就少了四个口，同时还要考虑对端设备端口密度。如果两台设备之间的互联端口本来就紧张，为了聚合再插四根线，可能还不如直接买两块万兆板卡。另外聚合对光纤和光模块的一致性要求很高，四对光模块里只要有一对的型号、波长、距离不匹配，就可能出现“端口 up 但收不到包”的诡异问题，排查成本比换模块高得多。

2. 核心原理拆解：聚合的账到底是怎么算的

2.1 LACP 的协商过程与主从角色

动态聚合跑的是 LACP 协议，它的作用不是“传数据”，而是“协商谁有资格转发”。整个过程可以理解为两个人在对暗号：双方周期性发送 LACPDU，报文里带着系统优先级、系统 MAC、端口优先级、端口号、端口 Key 这些字段。设备先比较系统优先级加系统 MAC 组成的系统 ID，小的那个成为主动端；然后由主动端根据对端的端口优先级和端口号，决定哪些端口被选中进入转发状态。没被选中的端口进入 hot-standby 状态，也就是热备，主用端口挂了它立刻顶上。

这里有几个参数值得单独拎出来说。系统优先级默认一般是 32768，数值越小越优先；端口优先级也是默认 32768，同样越小越优先。理论上你不需要动它们，但在跨设备聚合的场景下，两边设备的系统 ID 必须被“伪装”成一致，否则 LACP 会认为对端是两个不同的设备，聚合直接起不来。这就是为什么跨设备聚合必须依赖堆叠或者 M-LAG 这类技术，靠人工硬配是配不出来的。

超时时间是另一个高频踩坑点。LACP 有短超时和长超时两种，短超时大约 3 秒检测不到报文就认为链路故障，长超时大约 90 秒。短超时切换快，但对链路质量要求高；如果光衰大、链路有间歇性闪断，短超时会导致端口反复 up/down，业务跟着抖。我的习惯是：机房内部光纤链路用短超时，跨楼宇或走室外光缆的链路用长超时，宁可切换慢一点，也不要频繁震荡。

2.2 哈希算法才是决定带宽能不能叠加的关键

聚合口的负载分担靠哈希，设备会提取报文里的某些字段做哈希运算，算出一个值，再对成员口数量取模，决定从哪个口发出去。常见的哈希因子有：源 MAC、目的 MAC、源目的 MAC、源 IP、目的 IP、源目的 IP、源端口、目的端口、以及它们的组合。二层聚合只能用 MAC 相关字段，三层聚合可以用 IP 和端口。

这里有个非常关键的细节：哈希是单向的。A 到 B 的流量按 A 发出的哈希选路，B 到 A 的流量按 B 发出的哈希选路，两边选的可能不是同一条链路。这本身不是问题，但如果你的设备只支持基于源 MAC 的哈希，而一个网段里所有流量都从同一个网关 MAC 发出，那所有流量都会挤在同一条成员链路上，聚合等于白做。这就是所谓的“哈希极化”。

我一般这样选：服务器接交换机的二层聚合，用源目的 MAC 哈希；三层互联的聚合，用源目的 IP 加源目的端口哈希，五元组组合最均匀。如果你的设备支持可配置哈希并且业务流量特征明确，就按流量特征调；如果不确定，优先选五元组，普适性最好。压测的时候一定要多开几条并发流，单流压测看不出聚合效果，反而会让你误判配置有问题。

2.3 静态聚合、动态聚合、跨设备聚合怎么选

静态聚合的优点是兼容性好，缺点是没有协议校验。我踩过最惨的一次坑就是：一端配了静态聚合，另一端忘了配，结果交换机认为四条线是四个独立端口，生成树把其中三条阻塞了，业务看起来正常，但带宽只有一条，而且一旦拓扑变化就是广播风暴。所以只要对端支持 LACP，我一律建议上动态，多花五分钟配置，省掉后面几小时的排障。

跨设备聚合是进阶玩法，解决的问题是“单台交换机整机故障”。两台交换机做堆叠之后对外表现为一台逻辑设备，聚合口可以跨成员设备；或者用 M-LAG 这类技术，两台设备控制面独立但转发面协同。代价是配置复杂度陡增，任何一边的参数不一致都可能让聚合口起不来。中小型网络我一般不推荐，除非业务对连续性要求极高。

3. 落地前的规划与参数核对

3.1 端口、光模块、速率双工的一致性清单

聚合失败的原因里，至少一半出在物理层。我在动手配置之前会做一张核对表，逐项打勾，这个习惯是从一次半夜割接失败之后养成的。速率和双工必须两端一致，电口要强制成一样的，别一边自协商一边强制，容易出现一端 1000M 全双工、另一端 100M 半双工的荒唐结果。光模块的波长、传输距离、单模多模必须成对匹配，单纤双向模块还要注意 A/B 端的配对，插反了就是端口 up 但收不到包。MTU要在聚合口上统一设置，成员口继承聚合口的 MTU，如果两端 MTU 不一致，小包通、大包丢，ping 得通但业务传不了文件，这种问题最难查。

还有两个容易被忽略的点：一是节能以太网，部分设备默认开启，链路空闲时会降功耗，聚合场景下可能引起协商异常，建议关掉；二是流控，两端要么都开要么都关，一边开一边关会在拥塞时出现丢包策略不一致。这些参数单看都是小项，凑在一起就是“配置全对但就是不通”。

3.2 聚合组编号、模式与成员口的规划原则

规划阶段要定三件事：聚合组编号、聚合模式、成员口范围。编号本身无所谓，但要有规律，比如核心互联用 1-9，服务器接入用 10-49，方便后期看配置一眼就知道是干什么的。成员口尽量选连续的端口，一方面是配置省事，另一方面是同一块板卡上的端口时序一致，出问题的概率低；如果为了板卡冗余要跨板卡聚合，那就得接受单板故障时聚合组带宽减半的事实。

成员口在加入聚合组之前，必须把原来的业务配置清干净。一个端口如果已经配了 IP、划了 VLAN、绑了 ACL，直接加进聚合组，轻则配置被忽略，重则报错。正确顺序是：先清空成员口配置，再加入聚合组，最后在聚合口上配业务。这个顺序反过来做，你会发现业务怎么都不通。

注意：成员口加入聚合组后，不要再单独对成员口做业务配置。不同厂商的处理方式不一样，有的是直接拒绝，有的是静默同步到聚合口，有的是配置生效但不转发，第三种最坑。

4. 完整配置流程实录

4.1 交换机侧：从建组到成员加入

下面用通用伪命令描述流程，关键字各家不同，思路是一致的，实际敲命令时按设备手册替换。第一步建聚合组并指定模式，动态聚合要显式声明 LACP：

! 创建聚合组 10，模式为动态 LACP aggregate-group 10 mode lacp-static ! 设置负载分担方式为源目的 IP 加源目的端口 aggregate-group 10 load-balance src-dst-ip-port ! 加入成员口 interface port 1/0/1 aggregate-group 10 interface port 1/0/2 aggregate-group 10

第二步在聚合口上配业务。二层聚合口按 Access 或 Trunk 配，三层聚合口直接配 IP：

interface aggregate 10 description to-core-router switchport mode trunk switchport trunk allowed vlan 10,20,30 spanning-tree edged-port disable

这里有个顺序上的讲究：先配聚合口业务，再加成员口，还是先加成员口再配业务？两种都行，但我倾向先建组、配好聚合口参数、确认聚合口状态正常，再加入成员口。原因是成员口一加入就可能开始转发，如果聚合口上还没配好 VLAN 或 ACL，会有一小段流量“裸奔”。在割接窗口里，这点时间差可能就是事故和故事的差别。

4.2 路由器侧：三层聚合口的配置差异

路由器侧的配置逻辑一样，但要注意接口类型。很多路由器把聚合口定义为三层接口，成员口加入后自动变成二层属性，不能再配 IP。配置大概是这样：

interface aggregate 10 description to-access-switch ip address 192.0.2.1 255.255.255.252 mtu 9000 ! 成员口加入 interface port 0/0/1 aggregate-group 10 interface port 0/0/2 aggregate-group 10

如果路由器要在聚合口上做 VLAN 终结，就用子接口：

interface aggregate 10.20 encapsulation dot1q 20 ip address 192.0.2.5 255.255.255.252

子接口方式下，哈希因子会带上 VLAN 标签，流量分散效果通常比纯 IP 哈希更好。但要注意，子接口的 MTU 要按 VLAN 标签长度调整，否则大包会被丢。我一般把物理聚合口 MTU 设成 9000，子接口设成 8996，留出标签空间。

4.3 验证：怎么确认聚合真的生效了

配置完不要急着收工，按顺序验证四件事。第一看聚合口状态，确认成员口是不是都处于“已选中”状态：

show aggregate-group 10 detail show lacp neighbor show interface aggregate 10 counters

第二看 LACP 邻居关系，两端互相能看到对方的系统 ID 和端口状态，才算协商成功。第三看流量分布，在聚合口上连续看几次计数器，确认每个成员口都有收发字节增长，如果只有一个口在涨，说明哈希没散开。第四做压测，用打流工具开 8 到 16 条并发流：

iperf3 -c 192.0.2.10 -P 8 -t 60 -i 5

看总吞吐能不能接近聚合带宽的 80% 到 90%。如果四根千兆聚合，跑到 3.2G 以上就算正常，跑不满不一定是配置问题，哈希分布、TCP 窗口、接收端磁盘都可能是瓶颈。这一步的意义在于建立基线，以后出问题时有对比参照。

5. 常见故障与排查实录

5.1 聚合口起不来，或者只起来一半成员

这是最高频的问题。排查顺序我固定为：物理层、配置一致性、协议状态。物理层看端口是不是真的 up，有没有 CRC 错包、光衰是否正常；配置一致性看两端速率、双工、MTU、VLAN 列表、聚合模式是不是完全对齐；协议状态看 LACP 邻居有没有建立，端口是不是处于“挂起”状态。

只起来一半的典型原因有三种：一是对端有个成员口压根没配进聚合组，被生成树阻塞了；二是某个成员口的光模块有问题，端口 up 但收不到 LACP 报文；三是一端配了动态、一端配了静态，静态那边不认 LACP 报文，只能靠物理状态判断。第三种情况最隐蔽，因为聚合口本身是 up 的，业务也能通，只是带宽少了一半，不主动查根本发现不了。

5.2 聚合起来了但带宽不叠加

先别怀疑设备，先怀疑流量模型。开一条流测出 1G，不代表聚合失败，只代表这条流被哈希到了一条链路。用多流压测，如果多流能叠上去，说明聚合是正常的，问题在业务侧是单线程。如果多流也叠不上去，再查哈希算法：只按源 MAC 哈希的设备，在网关集中的网络里必然极化；只按源 IP 哈希的设备，在 NAT 出口场景下所有流量源 IP 都一样，也会极化。

还有一种情况是单向流量。比如备份流量从 A 到 B 是 4G 并发，但从 B 回 A 只有确认包，这时候你看到的“不平衡”是正常的。判断方法是看每个成员口的出方向计数，而不是进出相加。我见过有人拿总流量除以链路数来判断均衡，结果被单向流量的统计方式坑了半天。

5.3 环路、广播风暴与单向链路黑洞

静态聚合最怕的就是“一端聚合、另一端没聚合”。没聚合的那端把四根线当成四个独立端口，生成树只能阻塞其中三个，但如果生成树配置有问题或者端口开了边缘端口，立刻就是环路。现象是 CPU 飙高、MAC 表疯狂跳变、全网变慢。遇到这种情况，第一时间拔线，别犹豫，然后从一端开始逐根恢复，边恢复边看 MAC 表和端口流量。

单向链路黑洞是另一个隐蔽故障。光纤一头断了，端口状态可能还是 up，LACP 短超时会在一两秒内发现问题并把端口踢出转发，但静态聚合完全感知不到，流量继续往这条“发得出去、回不来”的链路哈希，表现就是概率性丢包，ping 十次通八次。动态聚合能规避这个问题，这也是我坚持用 LACP 的原因之一。

5.4 排查速查表

6. 几条用血换来的实操心得

第一条，割接前一定做回滚预案。聚合配置涉及两端，改一端的时候另一端可能就是断的。我的做法是先把新链路配好但不加入聚合组，确认单口能通，再一次性加入，出问题立刻把成员口移出、恢复原配置。整个过程控制在五分钟以内，比现场想怎么回滚靠谱得多。

第二条，聚合组的 MAC 地址会变。聚合口的 MAC 通常取系统 MAC 或者最小成员口 MAC，当你替换成员口、调整端口顺序时，聚合口 MAC 可能跟着变，导致对端的 ARP 表、邻居表震荡。所以在成员口稳定的环境里，尽量别频繁加减成员，要加就一次加到位。

第三条，别在聚合口和成员口上同时做镜像和抓包。聚合口抓包看到的是哈希之后的流量，你想抓某一条特定流的包，得先算出它走哪个成员口，再去成员口抓。这一点在做故障定位时特别重要，不然你会对着聚合口抓半天，发现想看的流量一条都没有。

第四条，记录哈希算法和超时配置。这两项在配置里不显眼，但换设备、换版本、别人接手的时候，它们往往是问题根源。我在每个聚合口的描述里都会写上对端设备、带宽、哈希方式，比如“to-core-sw01 4x1G lacp src-dst-ip”，一年后回来看，一眼就明白当初怎么设计的。

最后分享一个小技巧：如果你不确定聚合到底有没有生效，不要看带宽，看成员口的错误计数和 LACP 报文计数。真正健康的聚合，每个成员口的 LACP 收发计数应该持续增长且大致相等，一旦某个口明显偏低，说明它要么没被选中，要么在频繁震荡。这个判断比压测快得多，也准得多。