2. 链路冗余技术：EtherChannel（LACP/PAgP）原理与配置

说到链路冗余，很多人第一反应就是STP。但STP有个天生的毛病——它会把冗余链路给block掉。说白了，你明明多拉了几根线，结果只有一条在干活，其他的都在睡觉。这太浪费了。

那有没有办法让多条链路同时工作，还能互相备份？有，就是EtherChannel。我习惯叫它「链路聚合」。这玩意儿能把2到8条物理链路捆成一条逻辑链路，带宽叠加，故障自动切换。我在数据中心项目里，几乎每个机柜的上行都在用这个技术。

2.1 EtherChannel的两种协议：LACP vs PAgP

EtherChannel有两种协商协议。一个是IEEE标准LACP，一个是思科私有PAgP。我个人建议，能用LACP就别用PAgP。为什么？因为LACP是开放的，跨厂商兼容性好。你想想看，万一哪天机房要混用华为和思科的设备，PAgP就废了。

这里有个坑，我踩过。LACP的Passive模式不会主动发起协商，必须对端是Active才能建立。我曾经有一次配了两端都是Passive，结果链路死活起不来。排查了半天，发现两边都在等对方先开口。嗯，这就像两个人都在等对方先打招呼，场面一度非常尴尬。

2.2 链路聚合的负载均衡算法

很多人以为EtherChannel是把流量平均分配到每条链路上。其实不是。它用的是哈希算法。说白了，就是根据数据包的某些字段算出一个哈希值，然后决定走哪条链路。

默认情况下，思科设备用的是源MAC和目的MAC的组合。但我在实际项目中遇到过一个问题：如果所有流量都是同一个MAC对在通信，那哈希值永远一样，所有流量都挤在一条链路上，其他链路闲着。这就失去了聚合的意义。

所以，你需要根据业务场景调整算法。常见的算法有：

• src-dst-mac：基于源目MAC，适合二层环境
• src-dst-ip：基于源目IP，适合三层路由环境
• src-dst-port：基于源目端口号，适合NAT或负载均衡场景

我个人习惯在数据中心里用src-dst-ip。因为服务器之间的流量，IP对变化多，哈希分布更均匀。你想想看，几百台虚拟机互相通信，源目IP千变万化，每条链路都能跑满。

!
interface Port-channel1
 no switchport
 ip address 10.1.1.1 255.255.255.0
!
interface GigabitEthernet0/1
 channel-group 1 mode active
!
interface GigabitEthernet0/2
 channel-group 1 mode active
!
! 调整负载均衡算法
port-channel load-balance src-dst-ip
!

2.3 故障切换场景演示

EtherChannel的故障切换速度，比STP快得多。STP收敛要几十秒，EtherChannel只要几毫秒。为什么？因为EtherChannel检测到链路down了，直接重新计算哈希，把流量切到其他链路上。不需要像STP那样重新计算拓扑。

我记得有一次机房巡检，不小心踢掉了一根光纤。当时心里一紧，以为要出事故了。结果ping了一下，一个包都没丢。这就是EtherChannel的好处——故障对业务完全透明。

但要注意，EtherChannel只能检测物理链路故障。如果链路是通的，但质量很差（比如光衰大、误码率高），EtherChannel不会自动切换。我曾经遇到过这种情况：光纤被老鼠咬了一口，光功率掉到-25dBm，但链路没down。结果业务卡得要死，EtherChannel还在往那条坏链路上发流量。

另外，EtherChannel的故障切换有个细节：它只切换新流量，不会重传已经发送的包。也就是说，如果某个包正在坏链路上传输，链路突然断了，这个包就丢了。上层协议（比如TCP）会负责重传。所以，如果你的业务是UDP的，而且对丢包敏感，建议在应用层做冗余。

最后说一句，EtherChannel不是万能的。它解决的是链路层面的冗余和带宽叠加。但如果你要跨设备做冗余（比如两台交换机互为备份），那就得用MLAG或者VPC了。那是另一个话题，咱们后面再聊。

好了，EtherChannel这块就聊到这儿。这东西配置不难，但要想用好，得理解它的原理和局限。下次你配链路聚合的时候，想想我今天说的那几个坑，应该能帮你省不少事。