某局点无线组播应用跨产品线问题处理（无线+交换）经验案例

某局点无线组播应用跨产品线问题处理（无线+交换）经验案例

一、组网拓扑：

某校园网局点采用了我司WLAN设备（WX6000+WA2610H-GN）进行无线组播视频播放，采用三层组播架构（PM-DM）。接入交换机使用我司S5120SI，中间汇聚交换设备有C友商的S6509。

组网拓扑如下：

   

二、问题描述：

PC通过无线连接播放组播视频有卡顿，PC机直接连接在AP（WA2610H-GN）的有线口上做有线组播也存在卡顿现象。

三、问题定位过程：

整个应用是基于无线的组播应用，现场问题最开始反馈到无线二线。无线二线定位过程如下：

首先，由于在AP的有线口播放视频存在卡顿，开始怀疑整个有线的组播路由存在故障或者有线交换机存在丢包，总之怀疑有线网络存在故障。开始旁路AP和接入交换机测试有线组播。

（1）测试电脑直接连接在S6509交换机，旁路我司S5120SI做有线组播，组播视频播放正常。

（2）测试电脑直接连接在我司S5120SI上，旁路AP做有线组播，组播视频播放正常。

经过上述测试，简单判断后可以初步排除组播路由、交换机丢包、服务器故障的可能性。问题范围缩小到无线AP上。

由于无线空口丢包是最常见的故障，先检查空口环境，查看空口利用率、802.11协商速率都正常，不存在明显的WLAN干扰。再咨询无线研发是否有可能是这款低端AP（WA2610H-GN为SOHO级无线设备）组播性能不足的原因。研发初步判断后给了否定的答复，请求现场替换AP验证。

协调客户替换掉WA2610H-GN这款面板AP，用企业级的WA2610i-AGN来替换测试。测试结果意料之中，更换为企业级AP WA2620i-AGN后视频播放正常。再换回WA2610H-GN故障又复现。

是否有可能是这一台WA2610H-GN的故障？为了排除单台WA2610H-GN故障的可能，尝试更换为另一台同型号AP，故障复现。

到这里，故障已经很“明显”的锁定为无线AP的故障。一线强势要求无线产品线及研发定位并给出合理解释。一线售前及产品部也开始施压。

无线研发介入配合定位。无线二线开始在现场工程师配合下从AP丢包的思路出发尝试定位问题。测试中发现一个现象：（1）无线PC上进行ping包测试，从PC ping AP，查看AP的端口统计信息，都没有任何的丢包现象发生。（2）ping测试时延也很低。

AP测试没有丢包，无线研发给出的意见是在S5120SI连接核心交换机的上行口与连接AP的下行口同时抓包，由交换产品线配合定位。

现场通过在接入交换机S5120SI上、下行口同时镜像抓包，发现交换机上有丢包现象发生（差不多相同时间段内抓交换机两个接口的包，上行接口在同一时间内有137509个包，而下行接口只有99570个包）。

再次检查组网环境， S5120SI上联核心交换机端口为1000M口，下联AP接口协商为100M口（WA2610H-GN以太口为百兆端口）。于是现场做了如下尝试：强制S5120SI上行口为100M口测试，卡顿现象马上消失了。

到这里，定位到故障与S5120SI端口协商速率100M还是1000M强相关。我们又做了一次定位测试，恢复S5120SI上行口为1000M，下行口直连PC机并强制协商100M，测试有线组播视频，故障再次复现。

于是测试结论总结如下：即只要S5120SI上、下行口端口协商速率一致，故障消失；如果交换机上行端口协商速率大于下行口，故障复现。同时，该故障与下行口连AP走无线视频播放还是连PC走有线视频播放没有直接关系。故障焦点回到交换机端口缓存上。

中低端交换二线及产品线研发介入定位。

交换二线在产品线研发指导下，尝试通过配置交换机的burst-mode enable来使能交换机Burst突发功能，以提供更好的报文缓存功能和流量转发性能。一线现场测试后发现效果不佳。通过软件修改来提升交换机缓存能力，从而解决问题的办法失败。

长时间定位问题未得到有效解决，客户压力骤升。于是一线组织了由市场、售前SE、中低端交换二线、交换研发、无线二线、无线研发组成的会诊团讨论处理办法，输出了会议纪要。会议结论如下：

（1）由于S5120SI交换机buffer小，当突发流量超过设备buffer时，设备出现丢包，是硬件规格问题，无法通过软件升级解决。

（2）研发建议通过服务器调整配置或者第三方软件工具平滑视频流量，降低突发来规避问题。临时办法可以通过连接服务器交换端口强制为100M口解决。

（3）研发输出故障分析报告，由一线市场和售前SE向客户解释说明。

客户认可解释，并接受了强制连接服务器交换端口为100M的临时解决方案。该问题告一段落。

四、定位过程总结及经验教训：

该组播丢包问题虽未得到彻底解决，但根因已明确：交换机S5120SI缓存小，在存在高速打低速情况时，缓存不足导致丢包。彻底解决办法需要更换交换机为数据中心级的大缓存交换机。

回顾整个处理过程，有教训和经验可供学习。

（1）故障点出人意外的从无线产品转变到交换机。在前期的替换测试时（更换AP为企业级AP时故障消失），很直观的就锁定故障范围在AP上面。但最终证明是错误的。无线产品线花费了大量客户资源，找到交换机故障的确凿证据后才协调交换组处理。

教训：早些将问题通过notes抄送相关产品线，能更快速的协调到多个产品线资源介入，从而更快的定位问题。目前，问题扩散的渠道还仅限于notes，主要由一线推动，二线不同产品线之间没有直接打通。后续技术支持中心会优化CMS跨产品问题处理流程。从机制上保证相关产品线的资源能及时介入。

（2）问题处理过程中，一线工程师能每天发日报全程记录当天的操作及进展，专人跟进。邮件内容包括详细的组网及配置信息，操作过程，现象结论。这就保证了问题处理的连续性，以及在后续交换组资源介入时能方便的知晓和把握整个定位过程，避免了重复的验证测试，大大提高了后续定位的效率。

经验：问题处理专人跟踪负责、详细的信息记录都是问题得以快速定位的保证。目前由一线工程师发“问题处理日报”来保证，每天发日报，并准确的抄送相关人员以协调支持，这个良好习惯需要保持和发扬。