现场为校园epon光网络组网,大批学生反馈清明节开始到8号这段时间onu下的网络很卡顿,经排查发现2/2/0/10有大量mac漂移且最后刷新时间刚好为8号【图1】。并且看logfile的时候可以看到2/2/0/10:27onu接口从4月3日12点开始被检测出环路,然后4月8日23点29分解除环路,【图2】学生反馈网络卡顿的时候,与mac漂移开始与结束时间对得上,所以怀疑造成网络卡顿直接原因是2/2/0/10:27onu接口。
但是去现场查看了这个onu,仅发现学生拉了一根长网线从隔壁床接到了本床,经询问学生并没有私接路由器或交换机情况。
意思是现在溯源还是没有结果,那造成大量mac漂移的原因可能是什么呢?
而且就算是私接,onu在这之前1是配置了端口隔离,2是配置环路检测,不应该会造成整网卡顿,还是说是olt或者onu软件故障问题?或者学生撒谎?


onu-olt-s10508核心(二层透传)-友商核心交换机(网关)-拨号设备。olt型号为S7510X,版本号为7634P52,onu版本号et916a113
从现象来看不太会是软件问题,mac漂移是在聚合口1和olt2/2/0/10口上的,可以看下agg1接的是什么设备,同步查下这个设备的mac漂移记录,看看是否能看得到端倪
bagg1是10508交换机,10508交换机上看漂移记录时看到这台olt和两外一台olt有漂移,但是另外一台olt查看logfile的时候并没有看到loop和可疑的日志
最有可能的原因是:学生误操作(如长网线自环或连接了另一ONU网络)制造了一个超出你现有防环机制处理能力的环路。ONU的环路检测功能在这个特定场景下失效了,导致环路长时间存在。
为了彻底解决问题并避免未来再次发生,我建议你按下面的步骤来操作:
立即复测与模拟:在现场人员的监督下,让学生重新把之前那根长网线按照原样连接。然后,在OLT上实时观察环路告警和MAC漂移现象是否会重现。同时,在学生宿舍里用一台笔记本电脑接在ONU下,持续Ping网关,观察环路重现时网络中断的情况,从而彻底锁定故障源。
深入配置审查:仔细检查ONU的环路检测配置,确认其处理模式(action)是否为shutdown模式。如果不是,请尽快修改为shutdown模式,确保下次环路发生时端口能自动关闭。
制定长效机制:
技术加固:在核心交换机S10508上开启广播风暴抑制和未知单播抑制功能,作为最终防线,限制环路的危害范围。
人员管理:将此次案例作为典型进行全校通报,明确禁止在宿舍网络端口之间私自串接网线或设备,违规将暂停网络服务。同时,建立快速响应流程,当环路告警出现时,能立即通知运维人员远程或现场处理。
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
抄袭了我的内容
×
原文链接或出处
诽谤我
×
对根叔社区有害的内容
×
不规范转载
×
举报说明
bagg1是10508交换机,10508交换机上看漂移记录时看到这台olt和两外一台olt有漂移,但是另外一台olt查看logfile的时候并没有看到loop和可疑的日志