某大学 N18010 办公区三层转发丢包
一、故障现象描述
客户方办公网下对接友商设备上行S12708，N18K-S12708之间有丢包（非直连），下联用户ping S12708的管理地址丢包且延时明显增加2ms。将对应核心上联S12708的AGG 100成员口hun 1/2/12关闭之后，丢包与延时都恢复正常。
设备型号：N18010 设备版本：N18000_RGOS 11.0(4)B58P5, Release(10180613)
拓扑图：
二、故障排查分析
-
报障前客户方排查（上联口AGG 100，成员口hun 1/2/12、hun 2/2/12）：
-
客户shutdown hun 1/2/12端口发现不再丢包，初步怀疑是和板块/线路有关系。
-
客户更换hun 1/2/12的光模块、跳线，发现开启1/2/12端口丢包依旧出现，排除中间线路/模块问题。
-
客户更换对端S12708的端口，发现丢包依旧出现，排除对端设备问题。
-
客户替换N18K上hun 1/2/12至hun 1/2/11端口，发现丢包依旧，排除端口问题，怀疑和板块/设备有关。
-
客户将N18K hun 1/2/12替换至hun 2/2/11端口，对端设备端口不变，未出现丢包现象。
-
综上，线路问题、板卡接口问题已排除，主要针对流量架构或者硬件相关进行核查。
-
梳理客户方问题点，针对性梳理信息收集脚本（网关在汇聚，三层转发丢包），选取客户方异常时间段进行复现，异常时间段流量进行信息收集与排查。
梳理信息收集脚本如下（快转与PKT确认对应报文是否有送CPU、ACL计数核查三层转发丢包点）：
-
根据对应ACL计数，明确对应报文核心三层转发丢包，交换机往下行口转发丢包（无快转、PKT等回显，说明对应报文未送控制面处理，纯硬件转发）。
-
基于点3分析，基本明确对应报文交换机内三层转发丢包，主要需要分析对应三层报文在整个交换机内流量路径，基于流量路径分析对应丢包可能点。
-
设备为VSU架构，设备聚合口关闭本地优先转发，聚合口负载算法为源目MAC。即86E下用户流量上送至友商S12708按源目MAC负载方式，会存在几个可能性（明确对应流量86E负载至2机7线卡）：
-
S86E---2机7线卡---FE交换网板---2/2线卡---S12708
-
S86E---2机7线卡---7线卡VSL---FE交换网板---2/2线卡---S12708
-
S86E---2机7线卡---FE交换网板---4线卡VSL---FE交换网板---2/2线卡---S12708
-
基于上述流量路径，可能导致转发丢包的主备7线卡、主备4线卡、主备2线卡、FE交换网板、VSL接口。
-
通过之前异常时间段收集信息，并未发现明显的硬件记录，线卡/网板的异常的可能性较低。观察客户方正常时间段流量，发现对应VSL接口为万兆接口（观察时利用率高达75%），整网出口流量约15~20G，流量可能会出现超VSL可能性。
-
客户方安排窗口进行复现，收集对应异常时间信息，明确存在VSL带宽满溢情况，基本明确根因为VSL接口跑满导致的跨三层转发丢包。
-
针对客户方操作以及疑问进行核查。
问题一、如果是vsl跑满导致的丢包，上联接口down一根，应该会导致vsl流量更大才对，这个时候为什么业务恢复了？
梳理流量情况：
单1机上联情况下：上联进方向总流量约14Gbps，1机下联总流量3Gbps；2机下联总流量9.5Gbps。说明存在2机下联单边流量更大的情况。
单2机上联情况下：上联进方向总流量约14.4Gbps，1机下联总流量8.7Gbps；2机下联总流量21Gbps。说明存在2机下联单边流量更大的情况。
2机单边流量大，只保留单1机上联的时候，大多数流量都要从1机跨机箱转发到2机，所以VSL链路占用变大；拔除1机上联之后，上联流量都从2机进来，多数流量都从2机本机的下联送出去，VSL的负载变小。
问题二：期间有进行版本升级，前后业务模型，流量大小没有变化，为什么升级之后vsl才有跑满的情况出现？
VSL流量的负载，与下联终端流量的源MAC和目的MAC有关。
网关在核心的终端流量，三层流量目的MAC都是核心的MAC，所以终端不变、组网结构也不变的情况下，流量负载路径不会变，负载会受终端流量大小而产生差异。
网关在汇聚的终端流量，三层流量源MAC都是汇聚的MAC，目的MAC都是核心的MAC，组网结构不变的情况下，流量负载路径不会变，负载会受终端流量大小而产生差异。
三、故障根因说明
综合上述分析，对应跨机框流量超VSL接口带宽，导致对应聚合三层转发报文丢包，引发客户方业务网转发丢包和延时增大现象。
四、故障解决方案
替换对应10G VSL为40G VSL。
五、经验总结
针对高峰期出现业务丢包排查思路：
-
主要针对性的核查接口带宽、认证容量、ARP/MAC容量等性能相关限制。
-
异常流量路径进行梳理是必要的，梳理出路径才能明确可疑点。
-
异常时间上层的信息收集（接口利用率、接口drop等）是必要的，底层信息记录不是百分百准确。
版权声明：
作者：SE_You
链接：https://www.cnesa.cn/2599.html
来源：CNESA
文章版权归作者所有，未经允许请勿转载。
THE END
0
二维码
打赏
海报
某大学 N18010 办公区三层转发丢包
一、故障现象描述
客户方办公网下对接友商设备上行S12708，N18K-S12708之间有丢包（非直连），下联用户ping S12708的管理地址丢包且延时明显增加2ms。将对应核心上联S12708的AGG 100成员口hun 1/2/12关闭之后，丢包与延时都恢复正常。
设备型号：N18010 设备版本：N18000_RGOS 11.0(4)B58P5, Release(10180613)
拓扑图：
二、故障排查分析
报障前客户方排查（上联口AGG 100，成员口hun 1/2/12、hun 2/2/12）：
客户shutdown hun 1/2/12端口发现不再丢包，初步怀疑是和板块/线路有关系。
客户更换hun 1/2/12的光模块、跳线，发现开启1/2/12端口丢包依旧出现，排除中间线路/模块问题。
客户更换对端S12708的端口，发现丢包依旧出现，排除对端设备问题。
客户替换N18K上hun 1/2/12至hun 1/2/11端口，发现丢包依旧，排除端口问题，怀疑和板块/设备有关。
客户将N18K hun 1/2/12替换至hun 2/2/11端口，对端设备端口不变，未出现丢包现象。
综上，线路问题、板卡接口问题已排除，主要针对流量架构或者硬件相关进行核查。
梳理客户方问题点，针对性梳理信息收集脚本（网关在汇聚，三层转发丢包），选取客户方异常时间段进行复现，异常时间段流量进行信息收集与排查。
梳理信息收集脚本如下（快转与PKT确认对应报文是否有送CPU、ACL计数核查三层转发丢包点）：
武汉大学办公区N18K互联华为12708丢包复现收集信息
根据对应ACL计数，明确对应报文核心三层转发丢包，交换机往下行口转发丢包（无快转、PKT等回显，说明对应报文未送控制面处理，纯硬件转发）。
基于点3分析，基本明确对应报文交换机内三层转发丢包，主要需要分析对应三层报文在整个交换机内流量路径，基于流量路径分析对应丢包可能点。
设备为VSU架构，设备聚合口关闭本地优先转发，聚合口负载算法为源目MAC。即86E下用户流……
共有 0 条评论