典型ac-fit ap组网,集中转发
某局点反馈无线用户反馈上网不佳,存在丢包现象。
首先查看该局点ap较多为wa2610i,为2.4G,已经做过常规优化。现场反馈一个现象是空口偶发性增高,此时丢包可以接受。因为2.4g性能相对5G的确偏弱。但是为什么有时候空口低于30,但是还是存在丢包现象。这个需要定位原因所在
因为是集中转发,因此ac起二层地址,和终端互ping。发现问题依旧
推测定位丢包应该在ac到终端这段,那么可能是ac——ap端丢的,也可能是空口丢的。
排查有线侧,ac长ping ap发现存在偶发性大延时,丢包率在1%。
因此,首先需要定位为何有线侧还存在丢包,通过逐步排查发现ap上行口流量较大,有较多overruns报文,ap上行口单播报文每秒大概2000多,overruns报文数量也不断增加。
ap上行口广播报文并不大,关联ap也不多,为何单播报文这么多???
通过在ap上行口抓包发现,ap上行口有较多ac发给其他ap的报文,范围不仅仅是通一个接入交换机下的ap,ac发给其他交换机下ap的报文,也出现在该ap上行口。
和现场工程师确认抓包没问题,现场重新抓包,发现依旧存在该问题?
那么问题出在哪儿了呢?
通过查看ac表项,发现arp和mac表项均无问题。但是当看到核心的时候发现和核心偶发性的存在学习不到个别ap mac的情况,且ap不固定。
通过查规格,发现是核心mac表项满了,因此导致偶发性的学不到ap的mac。
这个也带来了一个问题,就是ac转发给ap或者终端的报文,核心如果没有mac地址的话,可能会认定为未知单播,因此在其下的设备中泛洪,这个就是ap上行口存在ac发往其他ap报文的原因。
因为ap上行口报文量太大,ap处理不过来,导致ac到ap偶发性丢包问题。这个也是为何在ap空口较好情况下依然存在丢包的原因。
现场协调更换核心设备,问题解决。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作