企业官网建设流程全解析

1. 链路聚合到底解决了什么问题

第一次接触链路聚合是在一个模拟器实验里，两台交换机之间只连了一根线，跑流量的时候直接卡成幻灯片。当时第一反应是换根更粗的线，但现实里线缆的带宽是有物理上限的，千兆口就是千兆口，万兆口就是万兆口，你不可能靠换一根"超级网线"把带宽翻十倍。链路聚合的思路就完全不一样了——既然一根线不够用，那就把多根线捆在一起，让它们逻辑上变成一根"粗线"。

这个"捆"的动作，在行业里叫链路聚合，英文是Link Aggregation，各家厂商叫法不太一样。在思科体系里它叫EtherChannel，在华为体系里叫Eth-Trunk，在通用标准里叫LACP（链路聚合控制协议）或者802.3ad。名字五花八门，但核心逻辑是一致的：把多条物理链路绑定成一条逻辑链路，对外只呈现一个逻辑接口，从而实现带宽叠加、链路冗余和负载分担。

我之所以拿思科模拟器来做这个实验，是因为它能把整个协商过程、状态变化、故障切换都直观地展示出来，比在真机上盲调要清楚得多。这篇文章适合两类人看：一类是刚学网络、搞不清楚EtherChannel和LACP区别的新手；另一类是配过聚合但总遇到"起不来""一边通一边不通"这类问题的朋友。我会从设计思路讲到具体配置，再到排查技巧，尽量把踩过的坑都摊开说。

需要先明确一个概念：链路聚合不是"带宽乘以链路数"这么简单。两条千兆线捆一起，理论带宽是2Gbps，但单条数据流的带宽上限仍然是1Gbps。因为聚合的负载分担是基于流的哈希算法，同一条流（比如同一个源IP到同一个目的IP）只会走其中一条物理链路。这一点很多人一开始会误解，以为捆两根线，单个大文件传输就能跑到2Gbps，实际跑下来还是1Gbps左右，然后就开始怀疑配置错了。不是配置错，是原理如此。

2. 核心概念与方案选型拆解

2.1 手工聚合与LACP协商聚合的区别

链路聚合在配置层面分两大流派，这个必须先搞清楚，否则后面配置的时候会一头雾水。

手工模式（Static/On模式）：两端的聚合口都强制设为On，不跑任何协商协议。只要两端配置的成员接口一致，聚合就能起来。优点是简单直接，不依赖协议报文；缺点是没有任何握手确认机制，如果一端配了聚合、另一端没配，或者成员口对不上，可能出现环路或者流量黑洞，而且自己不会报错，排查起来很痛苦。

LACP模式（动态协商）：两端通过LACPDU报文互相协商，确认哪些链路可以加入聚合组。它有一个"主动端"和"被动端"的概念，主动端负责决策哪些链路活跃。优点是可靠性高，一端配置有问题另一端能感知到，不会闷头转发；缺点是配置稍复杂，需要理解系统优先级、端口优先级这些参数。

我个人的建议是：只要设备支持，优先用LACP。手工模式看起来省事，但省的那点事在出故障的时候会加倍还回来。模拟器里两种都能做，但LACP能观察到的状态变化更丰富，学习价值更高。

2.2 二层聚合与三层聚合的适用场景

聚合口本身可以工作在二层，也可以工作在三层，这个选择取决于你的网络设计。

二层聚合（Layer 2 EtherChannel）是把聚合口当作一个交换口用，通常配置成Trunk，连接两台交换机。这是最常见的场景，比如接入层交换机上行到汇聚层，用两条线做聚合，既增加带宽又提供冗余。

三层聚合（Layer 3 EtherChannel）是把聚合口当作一个路由口用，上面直接配IP地址，通常用于两台三层设备之间的互联。这种场景下聚合口不参与VLAN标签的转发，纯粹做路由转发。

选哪个取决于你的拓扑需求。如果是交换机之间的互联，且中间要透传多个VLAN，那必须用二层聚合配Trunk。如果是两台核心设备之间做三层互联，那用三层聚合更干净。模拟器实验里我建议两种都做一遍，感受一下配置差异。

2.3 负载分担算法的选择逻辑

聚合组起来之后，流量怎么分配到各条物理链路上，是由负载分担算法决定的。思科设备上常见的算法有基于源MAC、目的MAC、源目的MAC、源IP、目的IP、源目的IP等。

这里有个实操经验：算法要选得"散"。什么意思？如果你的流量源IP很集中（比如都来自同一个服务器），那基于源IP的算法就会把所有流量压到同一条链路上，其他链路闲着，聚合等于白做。这时候应该选基于目的IP或者源目的IP的算法，让流量能分散开。

模拟器里默认算法通常是基于源目的IP的，这个在大多数场景下够用。但如果你的实验里发现某条链路流量特别大、其他链路很闲，就要考虑换算法了。这个细节很多教程不讲，但实际排障时经常遇到。

3. 模拟器环境搭建与基础配置实操

3.1 实验拓扑设计与设备准备

我用的拓扑很简单：两台三层交换机，中间用两条线互联，分别接在双方的GigabitEthernet0/1和0/2口上。两端各下挂一台PC用于测试连通性。这个拓扑足够演示聚合的建立、验证和故障切换。

设备选型上，模拟器里选支持EtherChannel的交换机型号即可，二层或三层都行，我这次用三层交换机是为了顺便演示三层聚合。接口速率统一用千兆，避免速率不一致导致聚合起不来——成员口的速率、双工模式必须一致，这是硬性要求，速率不匹配的接口无法加入同一个聚合组。

配置前先确认一件事：两端的成员口数量要对应。一端用了0/1和0/2，另一端也得用两个口，不能一边两个一边三个。LACP虽然能协商，但成员口数量不对等会导致部分链路处于备用状态，这个后面会讲到。

3.2 二层EtherChannel配置全过程

先做二层聚合。在两台交换机上分别进入接口配置模式，把成员口加入聚合组。

交换机A的配置：

SwitchA(config)# interface range gigabitEthernet 0/1 - 2 SwitchA(config-if-range)# channel-group 1 mode active SwitchA(config-if-range)# exit SwitchA(config)# interface port-channel 1 SwitchA(config-if)# switchport trunk encapsulation dot1q SwitchA(config-if)# switchport mode trunk SwitchA(config-if)# switchport trunk allowed vlan 10,20

交换机B做对称配置，channel-group编号可以不同，但模式要匹配。这里我用了mode active，表示主动发起LACP协商。如果一端active一端passive，也能起来；但两端都passive就起不来，因为没人主动发起。这个细节新手很容易踩。

配置完先别急着测，用show etherchannel summary看一眼状态。正常的话应该看到聚合组的状态是SU，其中S表示二层，U表示in use（在用）。如果看到的是D（down）或者P（bundled但standby），那就有问题，需要进一步查。

3.3 三层EtherChannel配置要点

三层聚合的配置略有不同，成员口加入聚合组后，IP地址配在port-channel接口上，而不是物理口上。

SwitchA(config)# interface range gigabitEthernet 0/3 - 4 SwitchA(config-if-range)# no switchport SwitchA(config-if-range)# channel-group 2 mode active SwitchA(config-if-range)# exit SwitchA(config)# interface port-channel 2 SwitchA(config-if)# no switchport SwitchA(config-if)# ip address 10.0.0.1 255.255.255.252

注意no switchport这个命令，它把二层口转成三层口。成员口和port-channel口都要执行，顺序上先成员口后聚合口。如果忘了在成员口上执行，聚合口配了IP也不通，因为物理口还是二层状态。

三层聚合起来之后，用show ip interface brief能看到port-channel口的状态是up，IP地址生效。这时候从对端ping这个地址应该能通。

4. LACP协商机制与状态验证

4.1 LACP报文交互与主动端选举

LACP的协商过程值得单独讲一下，因为理解了它，排查问题就有方向了。

两端启用LACP后，会互相发送LACPDU报文。报文里携带了系统优先级、系统MAC、端口优先级、端口号等信息。双方根据这些信息选举出一个主动端，主动端负责决定哪些链路进入活跃状态。选举规则是先比系统优先级（数值小的优先），优先级相同再比系统MAC（小的优先）。

主动端选出来之后，它会根据端口优先级决定哪些端口活跃、哪些端口备用。端口优先级数值小的优先活跃。如果成员口数量超过了设备支持的最大活跃链路数（比如有些平台一个聚合组最多支持8条活跃链路），多出来的链路就进入备用状态，主链路故障时才顶上。

这个机制在模拟器里可以观察到。你可以故意把一端的系统优先级调低，看它是不是变成了主动端。命令是lacp system-priority，在全局配置模式下执行。

4.2 聚合状态查看与关键字段解读

验证聚合状态主要靠几条命令，我把常用的列出来：

show etherchannel summary是最常用的，输出里每个聚合组前面有一串标志位。S表示二层，R表示三层，U表示在用，P表示捆绑中，D表示down，I表示独立（没加入聚合）。看到SU或者RU就是正常的。

如果看到成员口后面标的是P而不是U，说明链路捆绑了但处于备用状态，没在转发流量。这种情况通常是活跃链路数超限，或者对端配置有问题。

4.3 负载分担效果验证方法

聚合配好了，怎么确认负载分担真的生效了？光看状态是SU不够，得看流量。

模拟器里可以制造一些流量，比如从PC1持续ping PC2，然后看各成员口的收发包计数。命令是show interfaces gigabitEthernet 0/1和show interfaces gigabitEthernet 0/2，对比两者的input/output packets。

如果两条链路的计数都在增长，说明负载分担生效了。如果只有一条在涨，另一条不动，那可能是算法问题，或者流量本身就是单条流（单条流只走一条链路是正常的）。

想验证得更明显，可以开多个ping会话，源IP不同，这样基于源IP的算法就能把流量分散到不同链路。模拟器里可以用不同网段的PC来制造多源流量。

5. 常见故障与排查技巧实录

5.1 聚合起不来的典型原因

聚合起不来是最常见的问题，我整理了一个速查表：

我踩过最坑的一次是两端都配了passive模式，结果聚合死活起不来，查了半天才发现是模式问题。LACP要求至少一端是active，这个规则一定要记住。

还有一个隐蔽的坑：成员口的配置必须完全一致。如果一端0/1口配了Trunk允许VLAN 10，0/2口忘了配，那0/2口加入聚合组后可能被踢出来，或者导致整个聚合组行为异常。配置成员口的时候最好用interface range一次性配，避免遗漏。

5.2 流量不均衡的排查思路

聚合起来了但流量全压一条链路，这个问题也很常见。排查顺序是这样的：

先确认负载分担算法。用show etherchannel load-balance查看当前算法。如果是基于源MAC，而你的流量源MAC都相同（比如都经过同一个网关），那流量自然集中。换成基于源目的IP的算法试试。

再确认流量特征。如果实验里只有一条流（单个ping或者单个文件传输），那不管什么算法都只会走一条链路，这是正常的。要验证负载分担，必须有多条流。

最后看成员口状态。如果部分成员口是P（备用）状态，那流量当然只走活跃的那几条。检查活跃链路数限制和端口优先级配置。

5.3 故障切换测试与验证

链路聚合的核心价值之一是冗余，所以故障切换必须测。测试方法很简单：聚合正常运行的时候，把其中一条成员口的线拔掉（模拟器里可以shutdown接口），观察流量是否中断。

正常情况下，流量应该无缝切换到剩余链路，最多丢一两个包。如果流量中断了好几秒甚至完全不通，那说明聚合配置有问题，可能是LACP超时时间设置太长，或者备用链路没准备好。

LACP有两种超时时间：短超时（3秒）和长超时（90秒）。短超时反应快但报文多，长超时反应慢但开销小。默认是长超时，故障切换需要等90秒，这个在实验里会感觉很明显。想加快切换，可以配lacp rate fast改成短超时。

我实测下来，短超时模式下拔线切换基本无感，长超时模式下会断几秒。生产环境里如果对切换时间敏感，建议用短超时。

6. 进阶技巧与生产环境注意事项

6.1 跨设备聚合的思路

普通聚合的成员口都在同一台设备上，如果这台设备整个挂了，聚合再冗余也没用。跨设备聚合（比如思科的vPC、华为的M-LAG）就是解决这个问题的，成员口分布到两台设备上，任何一台挂了另一台还能顶。

模拟器里做跨设备聚合比较复杂，需要特定的平台支持。但思路要清楚：跨设备聚合需要两台设备之间有专门的同步链路，保证它们对聚合组的状态认知一致，否则会出现双活冲突。这个在实验环境里可以先了解概念，实际配置等有真机或者支持的环境再深入。

6.2 聚合与STP的配合

二层聚合口在STP里被视为一个逻辑端口，STP只在聚合口层面计算，不会对成员口单独计算。这意味着聚合组内的成员口不会因为STP被阻塞，这是聚合的一个隐性好处——既增加了带宽，又避免了STP阻塞链路。

但要注意，如果聚合配置有问题导致成员口被踢出聚合组，那个被踢出的口会重新参与STP计算，可能引起拓扑震荡。所以聚合的稳定性直接影响STP的稳定性，配置要仔细。

6.3 生产环境配置清单

如果要把这套配置用到实际环境，我建议按这个清单逐项确认：

• 成员口速率、双工、MTU一致
• 两端LACP模式至少一端active
• 成员口配置（Trunk、允许VLAN）完全一致
• 负载分担算法匹配流量特征
• LACP超时时间根据切换要求设置
• 聚合组编号两端可以不同，但成员口对应关系要清楚
• 配置保存，避免重启后丢失

还有一点，生产环境改聚合配置尽量在业务低谷期做，因为调整过程中可能短暂断网。模拟器里随便折腾，真机上要谨慎。

6.4 模拟器实验的局限与补充

最后说句实在话，模拟器再方便，也有它的局限。模拟器的流量是软件模拟的，负载分担效果和真机有差异；模拟器对某些硬件特性支持不全，比如某些平台的硬件哈希算法；模拟器的故障切换时间和真机也不完全一致。

所以模拟器里跑通了，只能说明配置逻辑没问题，真机部署前最好还是在测试环境验证一遍。特别是负载分担和故障切换这两个点，真机上的表现才是最终依据。

我个人在做这类实验的时候，习惯把每一步的验证命令和输出都记下来，形成自己的排查手册。下次遇到类似问题，直接对照手册查，比从头分析快得多。链路聚合这个技术本身不复杂，但细节多，坑也多，多练几遍把状态变化摸熟了，后面遇到问题基本看一眼状态就知道卡在哪。