问题描述：
网络接口无坏包，从SW2下行的终端云平台或cur后台ping各路口监控终端IP地址有八分之一的概率丢包，网络延迟在50ms-120ms之间。但从SW1 ping 各路口监控无丢包。将聚合口链路中任意一对链路单独剔除聚合，做透传时，无丢包。请问丢包情况是否与差异配置有关？
组网及组网描述：
组网类型为视频网络 网络中四台交换机俩俩堆叠，并每台交换机各引出俩根网线，共计8根网线，做4口聚合链路，聚合口采用lacp模式。在SW1交换机的一个成员接口中开启带宽最大限制9G，其余成员接口保持默认为10G带宽，同时在SW1的聚合口链路中，关闭stp生成树。SW2的聚合口stp生成树保持默认开启状态，聚合接口成员未开启带宽限制。SW1交换机下行通过运营商网络连接到了各路口监控摄像头，且各监控的网关都在SW1交换机上。SW2交换机下行还连接的监控系统云平台，以及CUR，且俩平台网关都在251交换机上。
1. 成员口状态：确认所有成员口均为Selected状态，无Unselected。
2. 负载分担模式：执行 `display link-aggregation load-sharing mode` 确认两端一致。
3. LACP系统优先级与端口优先级：确保两端无异常配置导致选路不一致。
4. STP状态：在聚合口及成员口上执行 `display stp brief`，确认所有相关端口均为Forwarding状态，无Blocking。
重点排查：你提到SW1的一个成员口配置了带宽限制9G，这是异常配置。在万兆或千兆聚合中，此限速可能导致：
- 该成员口实际吞吐被限制。
- LACP计算负载时，该口权重异常。
- 流量哈希到该口时被限速丢包。
建议操作：
1. 在SW1上移除该成员口的限速配置：进入该物理接口视图，执行 `undo qos lr outbound` 或对应的限速命令。
2. 再次测试丢包情况。
若问题依旧，需检查物理链路质量：在SW1和SW2上对聚合口执行 `display interface counters error` 查看是否有CRC、Giants等错误计数增长。
暂无评论
单独链路透传无丢包，聚合后就出现规律性丢包，这明确指向聚合链路内部负载分担不均或成员链路状态不一致。结合你提供的配置差异（带宽限制、STP状态不一致），基本可以确定丢包与差异配置有关。
问题核心分析
1. 关键现象解读
| 现象 | 结论 |
|---|---|
| SW2 ping 监控有丢包（约1/8），SW1 ping 监控无丢包 | 丢包发生在SW1 ↔ SW2 之间的聚合链路上，而不是监控终端侧 |
| 单独一对链路透传无丢包 | 物理链路本身没问题，问题出在LACP聚合的流量分发机制 |
| SW1聚合口一个成员限速9G，其他10G | 成员链路带宽不一致，LACP哈希可能将流量集中到限速链路导致拥塞丢包 |
| SW1关闭STP，SW2保持默认开启 | STP状态可能不一致，导致某些成员端口在SW2侧被阻塞，实际可用链路数减少 |
2. 丢包率1/8的数学暗示
1/8丢包率很可能是8条物理链路中有1条实际不可用或带宽受限，而LACP的哈希算法将约1/8的流量分配到了这条链路上。
丢包原因详细分析
原因一：成员链路带宽不一致 + 哈希不均
SW1的一个成员接口设置了9G带宽限制，其他为10G
LACP的哈希算法（通常基于源/目的IP、MAC等）会将流量均匀分布到所有成员链路，但不考虑链路实际带宽差异
当总流量接近或超过聚合口总带宽时，被哈希到9G链路的那部分流量会拥塞丢包
你从SW2 ping监控，流量从SW2→SW1，经过聚合链路时，约1/8的ping包被哈希到那条9G链路，正好产生约1/8的丢包率
原因二：STP状态不一致
SW1的聚合口关闭了STP，SW2的聚合口保持默认STP开启
在LACP聚合中，STP通常将聚合口视为一个逻辑端口，但如果配置不一致，可能导致：
SW2侧STP阻塞了部分成员物理端口（即使LACP认为它们是Up的）
实际可用的物理链路数少于8条，进一步加剧哈希不均
可以执行
display stp brief查看SW2聚合成员端口的STP状态
原因三：LACP超时模式不一致（可能）
如果一端配置了
lacp period short（快速超时），另一端为默认慢速超时，可能导致链路状态同步延迟，间歇性丢包
解决方案（按优先级）
第一步：统一成员链路带宽配置（最关键）
第二步：统一STP配置
第三步：检查并统一LACP参数
如果流量特征明显（如大量相同源/目的IP），可以调整哈希因子，避免流量集中到单条链路：
验证步骤
1. 确认成员链路状态一致
在SW2上持续ping监控IP，观察丢包率是否消失
如果还有丢包，可以逐条剔除成员链路，定位具体是哪条链路导致
3. 监控聚合口流量分布
暂无评论
结论（先给你）
- SW1 ping 摄像头不丢包（不走跨聚合）
- 云平台 / CUR → SW2 → 聚合 → SW1 → 摄像头 有 1/8 丢包、时延 50～120ms
- 拆掉聚合、单线直连就完全不丢包
- 聚合里一条口限速 9G、其他口 10G
- SW1 聚合关 STP，SW2 聚合开 STP
一、我逐条拆你问题根源（非常关键）
1）聚合成员口 带宽不一致（致命）
- 一条成员口：shaped /limit 9G
- 其他三条：默认 10G
- 抖动变大
- 时延涨到 50～120ms
- 看不出坏包（是队列丢包，不是物理错包）
一句话
2）两端聚合 STP 不对称（严重隐患）
- SW1 聚合：关了 STP
- SW2 聚合：默认开 STP
- BPDU 收发不对称
- 部分链路短暂阻塞、震荡、迂回
- 哈希流漂移
- 偶尔闪断、时延波动、小概率丢包
3）跨聚合流量负载分担不对（业务路径问题）
- 多路监控大流量、对称流少
- 哈希命中不均
- 不均匀带宽 + 不对称 STP = 极易丢包
4）视频业务最忌：乱序、跨端口哈希、不对称链路
二、为什么单拉一条线、不聚合就好了？
- 没有分担
- 没有限速差异
- 没有 STP 不对称
- 没有乱序
- 没有队列挤压
三、你现场四个硬性错误（整改即可根治）
错误 1：聚合成员口不能出现不同带宽
错误 2：两端聚合 STP 不一致
int Bridge-Agg 1
undo stp enable
错误 3：没有按源目 IP + 端口做最优负载
link-agg load-sharing mode source-dst-ip
错误 4：跨三层、跨聚合、UDP 视频天然敏感
- 聚合不要拆分同一流
- 不要异构链路
- 不要不对称配置
四、最简判定（你一秒确认）
dis q queue int g 1/0/1
dis int g 1/0/1 drop
五、一句话总结（最重要）
- 聚合里一条口 9G、 others 10G → 不均 → 1/8 丢包
- 两端 STP 一开一关 → 震荡时延
- 跨聚合 UDP 视频 → 乱序敏感、放大丢包
- SW1 本地 ping 不丢
- 跨聚合 ping 必丢
- 拆聚合单线完全正常
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论