上周帮客户排查视频会议卡顿，发现核心交换机启用了双链路STP冗余，但实际流量全压在主链路上，备用链路空转。客户第一反应是：‘是不是冗余配置把带宽吃掉了？’——这问题问得挺典型，也挺有代表性。
冗余本身不占带宽，但配置不当真能拖后腿
网络冗余，比如双上联、HSRP/VRRP、链路聚合（LACP）、OSPF多路径，本质是‘多备一条路’，不是‘多开一条道跑车’。它不主动吞带宽，但有几种情况会让网速变肉：
1. STP阻塞端口，等于白铺一根线
老式二层网络常用生成树协议防环。启用后，备用链路会被STP强制置为blocking状态——物理通，逻辑断。你看到两根光纤插着，其实只有一根在传数据。这时候冗余是‘冷备’，对当前网速零影响，但也毫无提速作用。想让两条都干活？得换MSTP或干脆上堆叠/IRF。
2. 负载均衡策略太糙，流量挤成‘单行道’
比如用静态路由做双出口冗余：
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 192.168.2.1 103. 冗余协议自身开销反成瓶颈
VRRP心跳包默认每秒发1次，量不大。但若在千台终端的局域网里，上百个VRRP组+高频率通告（比如改到100ms），控制报文就能占掉几Mbps。更隐蔽的是BGP full-mesh场景：10台路由器全互联，会建立45条会话，每条都同步路由表——CPU和内存顶不住时，转发延迟就上来了，用户刷网页就感觉‘卡一下’。
真正提升网速的冗余，长这样
某电商公司CDN边缘节点用LACP聚合4条1G链路，搭配基于源IP+端口的哈希算法，大文件下载时四路并进，单TCP流也能跑到900Mbps+；另一家医院HIS系统用vPC（思科虚拟Port-Channel）把两台接入交换机逻辑合成一台，服务器双网卡绑定active-backup模式——平时主卡跑满，主链路断了0.2秒内切到备卡，医生开电子病历完全无感。
关键不在‘多’，而在‘协同’：链路聚合要两端协商一致，路由冗余要配合BFD快速检测，无线AC冗余得同步客户端会话……否则冗余只是柜子里摆着的备用轮胎，路没塌它不转，路塌了还卸不下来。
自查小动作
登录核心设备，敲几条命令看看真实状态：
show etherchannel summary # 查LACP是否UP且所有成员ACTIVE
show spanning-tree active # 看STP有没有不该blocking的端口
show ip route 0.0.0.0 # 确认默认路由是不是真有多条等价路径
show bfd neighbors # BFD状态是否UP，检测时间是否合理（建议设为3×50ms）