锐捷N18010 线卡CPU异常整网中断

关键词：

一、故障现象描述

1. 对应3线卡下1/3/38-44接上POE交换机
2. 业务高峰期 两个条件叠加情况下就会触发整机线卡CPU拉升，转发异常。将对应1/3/38-44下POE交换机移到4线卡下即使业务高峰期也不会触发异常。

二、故障排查分析

1. 11月12日接到客户方报障，优先进行了业务恢复，恢复后根据现象核查异常时间段日志，异常时间段出现多协议（OSPF/LACP/LLDP）异常，同时发现对应CPP中存在队列丢包，怀疑异常时间段存在环路或者异常大量协议面报文上送，导致CPP带宽打满无法正常处理其他协议报文。

2. 后续通过抓取异常时间段报文以及信息收集，排除环境环路以及AP大量异常协议面报文上送导致控制面打满疑点。

3. 上层检查show cpu未发现异常，后续核查对应ssc_process处于12.5%就是满载的情况了（一共8个核，这边显示的就是均值，其中ssc_process运行在其中一个核，12.5%就代表对应单核跑满了）show process cpu nozero。

4. 协调客户方进行相关故障复现，明确对应故障触发前提：1、业务高峰期时间段； 2、1/3线卡38-44 POE交换机接入（即1/3线卡满载POE交换机）。
5. 异常时间段观察到对应引擎CPU异常线程为ssc_mac_th、libssd_mac_th，相关进程主要负责MAC相关处理，大量的MAC变动会导致引擎相关线程利用率拉升，同时mac变动需要同步所有线卡，导致所有线卡CPU拉升。// 线卡由于封shell，无法使用top -H命令，使用execute diagnose-cmd hardware 0 0 top 无法按利用率高排序显示线程；后续是通过execute diagnose-cmd top -Hp pid（PID按show cpu对应进程核查）不加hardware查看到引擎的对应两个线程异常。

6. 基于上述线程机制，需要进一步了解客户方架构和用户行为，与客户方沟通了解，新上的11台交换机都是属于同一个物理区域位置的POE交换机；设计上准备分布在核心1/4/41-44、1/3/38-44接口。
7. 叠加对应客户方高峰期才会出现异常的情况，分析客户方POE下用户行为，怀疑是高峰期存在大量的无线漫游，导致线卡间MAC变动频繁，引发设备整机线卡CPU升高。
8. 11月21日19点选取异常时间段对应1/3/38口下两个用户，查看对应用户认证轨迹，发现对应用户确实存在跨线卡迁移情况。

9. 22日对应新增的POE交换机均放置在4线卡下，选取约8个用户的认证轨迹，基本均为同板卡MAC变动。

10. 内部针对客户方环境进行复现搭建，跨线卡MAC变动的情况下，确实会导致整机线卡CPU拉升的情况，同线卡MAC变动情况下，不会拉升整机线卡CPU（具体同线卡变动不会拉升CPU原因在核查，后续主要也是从这个方向去优化跨线卡拉升CPU）。

三、故障根因说明

四、故障解决方案

五、经验总结

1. 主要针对性的核查设备性能容量相关限制，比如认证容量、ARP容量、MAC容量、处理性能容量等。
2. 排除环境异常报文的情况下，可以针对性分析客户方用户的行为，从行为特征进行逻辑分析。
3. CPU异常，先核查对应异常占用组件，根据对应可能引发组件功能异常可能性进行反查。