锐捷N18K有线核心网络卡顿且丢包

SE_You • 2024-12-16 • 交换机 • 10 阅读

一、故障现象描述

终端跨有线核心访问监控区域的摄像头地址存在严重丢包，终端上访问摄像头的管理页面白屏，无法正常显示。
将一台测试PC接在摄像头所在的交换机下，跨核心ping测试PC，ping常规74字节长的ping包无丢包，ping数据长度为1400字节的报文则丢包情况非常严重，丢包率30%以上。

二、故障排查分析

1、确认丢包点

排查动作
故障现象只有ping长度较长的报文时存在丢包，为一次性确认丢包点，需要执行以下排查动作：
  • 在核心、汇聚、接入设备上报文的进出接口配置ACL计数，统计ping包的接收和发送数量。
  • 汇聚侧PC和摄像头所在接入上的测试PC互ping50个长度为1400的报文，期间两台PC同时抓包。
排查结果
  • ACL计数结果表明，核心、汇聚、接入设备上报文的进出接口和进出方向的计数结果均为50，未发生收发丢包。
  • 两端PC上抓取到的request报文和reply报文数量都是50个，说明request、reply报文均未在设备传输过程丢包。
  • 终端收到的reply报文中，部分存在ICMP checksum error，且checksum错误的报文数量与ping丢包显示“请求超时”的数量一致。
  • 对比原始发出的reply报文和终端接收到的reply报文，发现ICMP data字段内容发生了变化
丢包点排查结果分析
从排查结果可以看出，丢包没有发生在网络设备上，丢包原因是reply报文内容在传输过程中发生了变化，被接收报文的终端PC判断为非法报文而丢弃，产生了丢包现象。需要进一步排查报文内容在传输过程中发生发生错误的原因。

2、ICMP data字段内容错误原因分析

因为报文内容发生变化的位置是ICMP data字段，该字段属于报文的载荷内容，传输路径中报文经过的设备都是交换机，交换机在传输过程中是没有业务组件会对报文载荷内容其进行修改或调整，所以可排除业务组件对报文处理错误导致的ICMP data字段内容错误。会导致ICMP data字段内容发生变化的可能性有两种：
  • 交换机HG口存在故障，可能会导致报文传输时发生数据信号位错误，进而导致报文字段内容发生错误。
    • 此情况可以通过在底层观察设备是否出现DPSP协议报文校验错误日志来判断。
  • 交换机转发报文过程中报文要先缓存在MMU内，如果MMU存在硬件错误或者运行中发生了bit跳变，则会导致对应cell下缓存的报文bit位发生错误，导致报文内容发生变化。
    • 此情况当前暂无软件层面的排查手段，现场业务流走向在核心上会经过1/1线卡、2/1线卡、FE交换网板、1/3线卡、2/3线卡，每张线卡、交换网板、引擎都有独立的MMU，所以想定位具体的故障MMU位置，需要通过线卡拔插测试和业务切换测试来绕开业务流量经过的MMU来判断。
排查动作
  • 排查交换机HG口：
      • 进底层，进线卡查看是否存在DPSP-error的pkt crc chk fail报错
    session device 2 slot m1  //登陆到从设备
run-system-shell   //进shell
me   //确认当前所在位置是否为2/M1
lc 3  //进入2/3线卡
sh
me  //确认当前所在位置是2/3线卡还是1/3线卡
---观察5分钟，确认该板卡是否有目标日志刷出，记录观察结果后切换其他线卡
Ctrl 2 //退出console
e  //退出线卡

lc 3  //进入1/3线卡
sh
me  //确认当前所在位置是2/3线卡还是1/3线卡
---观察5分钟，确认该板卡是否有目标日志刷出，记录观察结果后切换其他线卡
Ctrl 2 //退出console
e  //退出线卡

//继续观察主备机其他线卡、FE交换板卡和引擎
      • 在线卡上开启debug，明确报错的HG口，锁定线卡和FE卡对应关系。
    //先进到线卡shell层
cmd show-map  //查看线卡通路HG口映射表
cmd show-connect  //查看线卡连接HG口的信息
at //进入at模式
load dpsp_re_pk  //连接到dpsp模块
set_dbg_level 4 1  //开启debug开关，日志级别为4（基本全部打印）
---等待crc fail日志打印出来
set_dbg_level 4 0  //关闭debug开关
quit  //退出at模式
Ctrl 2 //退出console
e  //退出线卡
    • 注意，有业务的情况下开启线卡底层debug可能会导致日志刷屏无法退出，引起设备的线卡CPU爆满，需要在无业务的情况下进行线卡debug。
  • 排查MMU故障位置：
    • 错误报文接收端是接在2/3线卡，对2/3线卡进行拔插操作，排查是否为2/3线卡MMU运行过程中bit位跳变导致故障。
    • 将2/3卡的业务切到其他业务卡，观察故障现象是否消失，如果消失说明可能是2/3线卡和对应FE卡出现故障。
排查结果
  • 排查交换机HG口
      • 在2/1、2/2、2/3线卡和FE卡都存在报错，需要进一步进线卡开启底层debug缩小范围。
      • 底层debug，报错日志提示的hg_id是56，对应的对端Slot设备是2/FE2。
  • 排查MMU故障位置：
    • 拔插2/3线卡，故障现象依旧。
    • 将2/3卡的业务切到2/1线卡之后，观察故障现象消失。
ICMP data字段错误排查结果分析
从排查结果可以看出，2/FE2交换板卡存在HG口故障，导致了DPSP报文错误。2/3线卡可能同时存在HG口和MMU故障，导致业务报文经过2/3线卡后发生内容错误。

三、故障根因说明

有线核心的2/3线卡和2/FE2交换板卡存在MAC芯片故障。
  • 2/FE2卡HG口存在硬件故障导致发送到2/1、2/2、2/3线卡的DPSP协议报文出错导致三张业务线卡上都出现了pkt crc chk fail报错。
  • 2/3线卡HG口和MMU存在硬件故障，导致部分业务长度较长的报文在经过2/3线卡之后出现内容错误，引起终端丢包，导致出现了终端跨有线核心访问监控区域的摄像头地址存在严重丢包，终端上访问摄像头的管理页面白屏，无法正常显示的现象。

四、故障解决方案

1、客户现场通过替换2/3线卡和2/FE2交换板卡解决业务影响。
2、现场的故障件寄回硬件研发详细分析硬件故障的原因。

五、总结与建议

1、丢包点的排查需要了解清楚客户业务流量转发路径，设计好定位方案，执行后一次找到。
2、线卡底层开启debug要先把业务切走。

版权声明：
作者：SE_You
链接：https://www.cnesa.cn/2598.html
来源：CNESA
文章版权归作者所有，未经允许请勿转载。

THE END
分享
二维码
打赏
海报
锐捷N18K有线核心网络卡顿且丢包
一、故障现象描述 终端跨有线核心访问监控区域的摄像头地址存在严重丢包，终端上访问摄像头的管理页面白屏，无法正常显示。 将一台测试PC接在摄像头所在的交换机下，跨核心ping测试PC，ping常规74字节长的ping包无丢包，ping数据长度为1400字节的报文则丢包情况非常严重，丢包率30%以上。 二、故障排查分析 1、确认丢包点 排查动作 故障现象只有ping长度较长的报文时存在丢包，为一次性确认丢包点，需要执行以下排查动作： 在核心、汇聚、接入设备上报文的进出接口配置ACL计数，统计ping包的接收和发送数量。 汇聚侧PC和摄像头所在接入上的测试PC互ping50个长度为1400的报文，期间两台PC同时抓包。 排查结果 ACL计数结果表明，核心、汇聚、接入设备上报文的进出接口和进出方向的计数结果均为50，未发生收发丢包。 两端PC上抓取到的request报文和reply报文数量都是50个，说明request、reply报文均未在设备传输过程丢包。 终端收到的reply报文中，部分存在ICMP checksum error，且checksum错误的报文数量与ping丢包显示“请求超时”的数量一致。 对比原始发出的reply报文和终端接收到的reply报文，发现ICMP data字段内容发生了变化 丢包点排查结果分析 从排查结果可以看出，丢包没有发生在网络设备上，丢包原因是reply报文内容在传输过程中发生了变化，被接收报文的终端PC判断为非法报文而丢弃，产生了丢包现象。需要进一步排查报文内容在传输过程中发生发生错误的原因。 2、ICMP data字段内容错误原因分析 因为报文内容发生变化的位置是ICMP data字段，该字段属于报文的载荷内容，传输路径中报文经过的设备都是交换机，交换机在传输过程中是没有业务组件会对报文载荷内容其进行修改或调整，所以可排除业务组件对报文处理错误导致的ICMP data字段内容错误。会导致ICMP data字段内容发生变……
<<上一篇
下一篇>>