CNESA - SE_You的文章

SE_You 的文章

交换机

锐捷N18K 线卡异常重启

一、故障现象描述 4.28号开始，全校网络频繁出现中断问题，现场技术人员排查发现上行接口1/5/14口频繁出现UP/DOWN情况，导致网络异常。二、故障排查分析通过分析现场日志发现1/5线卡频繁出现离线上线情况，由于学校的出口以及VSL链路均在此卡上，所以此刻异常会导致VSU分裂以及出口异常。而引起Slot 1/5 频繁上下线的原因是设备温度超过shutdown温度导致的。日志信息如下： “%DEV_MONITOR-1-CARD_TEMP_OVERFLOW: The temperature of card in slot 1/5 is over danger value, it will be controlled to shutdown automatically”然后1/5线卡被下电。“*Apr 28 13:43:28: %DEV_MONITOR-1-CARD_POWER_OFF: Card in slot 1/5 is powered off.” 查看1/5下线卡的温度情况，发现Mac芯片超过了shutdown温度100度，所以会频繁重启。截图如下：进一步排查影响设备温度的因素，观察设备风扇、温度、电源以通风口正常，用手触摸设备不烫。通过沟通现场机房空调不是特别好，机房温度有27度左右。初步判断导致此线卡Mac芯片温度高的原因是环境温度过高以及此线卡数据转发过多导致的; 由于处于同一个运行环境中的主机上的其他线卡以及备机上的线卡的Mac温度相对于1/5线卡来说要低的多，需要升级进一步判断下1/5线卡是否存在元器件老化或是损坏; 研发通过调整风扇转速等级测试1/5线卡Mac芯片是存在问题，通过调整风扇等级为7，通过观察发现温度降到72度左右，业务维持正常。研发判断温度可以降低说明Mac芯片大概率没有硬件问题。但是温度依然很高，研发怀疑线卡内部有灰尘或是散热器存在问题，需要进一步排查。截图如下：根据研发建议输出下一步计划：（未进行）针对Slot 1/5线卡温度过高的排查： 1.现场进行主备切换，将业务切换到备机上，观察业务使用情况。 ① 下行业务均需要双上线线路 ② ……

SE_You 2024-12-30

4 0 0
交换机

锐捷N18010 FE卡心跳超时导致重启

一、故障现象描述设备型号版本：N18010 RGOS 11.0(4)B3 设备运行过程中FE3突然提示硬件心跳超时：并对该FE卡进行了复位重启，由于现场为VSU组网并存在多张FE卡冗余，暂未影响到业务。 *May 31 2024 08:52:26.128: %KEEPALIVE-3-MODULE_TIMEOUT: (*2/M1) Module in slot FE3 keepalive timeout. *May 31 2024 08:52:26.130: %DP-3-RESET_MODULE: (*2/M1) Reset module 2/FE3 due to hardware heartbeat timeout. 二、故障排查分析 5月31日，设备运行过程中FE3突然心跳超时线卡重启。收集信息发现FE3存在coredump，时间和FE3重启时间一致，基本确认是coredunp 导致FE3线卡重启。研发侧收集故障FE卡的coredump文件并解析，发现coredump死在系统链表108行。对比故障现象及内部处理记录，发现该coredump与2018年1月6号出现的18K FE1线卡KA超时的coredump死机节点一致。确认是同一个问题故障复发。三、故障根因说明该已知问题定位的原因是编译工具链版本较老。分析工具链glibc的修订, 发现sdk2.3 build128有一处修订在sem_post()里面释放锁的原子量前后都加了syncw, 从代码修订来看,是临时修订.通过Cavium相关手册, 确定了write-buffer, sync, syncw等相关原理: CPU内每个核有2KB的Write Buffer, 通过sync*进行CPU核间数据的同步.其中syncw只同步写操作, sync读写操作都会同步。继续分析sem_post()代码, 发现里面使用atomic_compare_and_exchange_bool_acq (&isem->value, cur + 1, cur)来操作原子量, 这个原子量函数宏里在原子量操作完后再执行syncw(相当于内存屏障), 这样无法保证原子量和前面的链表操作哪个先同步完成. 如果原子量先同步到其它核, 链表操作还未同步, 就会造成其它核获取信号量成功, 然后操作链表, 相当于信号量保护失效。分析Cavium在SDK2.3代码,发现已修复……

SE_You 2024-12-27

8 0 0
交换机

锐捷S2910E 多台设备反复异常重启

一、故障现象描述某客户使用我司2910C设备作为接入交换机，多台设备反复出现多次异常重启的情况。设备型号：RG-S2910C-24GT2XS-HP-E 设备版本：S29_RGOS 11.4(1)B70P1 二、故障排查分析接到客户方报障多台2910C出现重启行为，分析设备日志以及软件记录信息，核查均为冷重启，且软件上无任何异常记录。核查对应软件内部BUG库，并未找到会导致设备异常重启的软件BUG，结合客户方多台设备异常重启，初步怀疑异常时间设备供电异常导致。针对客户方8台2910C设备重启行为和重启时间进行梳理，寻找对应规律和行为特征。对应设备行为和重启时间上没有明显的特征，与客户方明确对应环境接线以及环境供电方面差异。明确对应供电S2910C=>UPS=>PDU=>市电。派遣对应省区一线前往现场进行环境供电核实以及排查，发现对应客户方市电确实存在不稳情况，电脑直连PDU情况下，出现了掉电的情况; 基于市电不稳的固有背景条件下，核查对应同一UPS下，为什么仅有我司设备存在重启行为。现场通过多次拔插对应UPS供电，模拟市电不稳环境因素，成功复现S2910C重启，友商设备未重启情况。了解对应UPS切换间断时间为4-8ms，内部拉通核实2910C当前使用电源模块切换间断为6ms，与UPS参数存在差异，当UPS间断时间超6ms，就会导致电源模块下电设备重启行为。三、故障根因说明我司当前型号适配电源模块实测切换时间在6ms，客户方当前UPS的切换间断为4-8ms，当UPS间断时间大于6ms，就会导致设备掉电重启，考虑电源模块单体和UPS单体之间的差异（叠加客户方市电不稳的固有环境因素），概率性会出现部分电源模块出现在UPS切换时掉电导致设备重启的行为。四、故障解决方案 1、针对当前电源模块线路进行整改，整改后对应切换间断时间可达到12ms，满足客户方UPS切换间断要求。五、经验总结 1、按照……

SE_You 2024-12-26

6 0 0
交换机

锐捷SF2910 运行过程中设备反复重启

一、故障现象交换机作为网络接入设备，设备使用时间一年以上，运行过程中突然出现不断重启，并且无法执行命令。并反复弹出以下日志：场景拓扑接入交换机作为网络接入设备，下联办公业务。二、故障排查分析正常设备的重启显示日志，提示ctrl+c进入ctrl模式恢复主程序；但该故障设备，日志未提示ctrl+c操作，无法进入ctrl恢复主程序，尝试重新灌装软件也无法恢复；设备弹出异常日志“NAND:iProC NAND chip could not be initialized”，表示设备NAND flash异常，可以判断设备存在硬件问题；三、故障根因说明设备硬件故障。四、故障解决方案异常日志“NAND:iProC NAND chip could not be initialized”，表示NAND flash异常，可以判断设备存在硬件问题，建议客户寄送修设备。寄送修指南：微信公众号“锐捷服务”--“服务支持”--“自助保修”中自行保修。

SE_You 2024-12-25

13 0 0
交换机

锐捷设备网络丢包故障排查SOP

一、故障现象终端或者交换机ping外网或者内网其他设备存在丢包情况。二、组网拓扑常规网络拓扑如下：拓扑描述： PC通过接入、汇聚交换机连接到核心，PC的网关在核心上，核心往上通过安全设备，路由器连接到外网。三、可能原因环境异常，导致对应MAC漂移、ARP变动、CPP队列丢包等；性能限制，对应流量超交换机接口带宽、转发容量、背板带宽等；配置限制，对应接口配置端口限速、QOS限速等流量策略；四、处理步骤：先梳理丢包源目的流量路径（需要特别注意是否有极简X SC方案，若有，流量路径需要将旁挂设备纳入），基于流量路径通过ACL计数，界定出对应丢包设备，针对异常丢包设备核查丢包根因。梳理对应故障时间线，明确故障前客户行为、客户操作、故障是否存在规律，分析是否与设备性能/接口带宽/容量限制/方案架构等关联因素。执行show logg命令，核查历史日志，明确对应时间段是否有存在异常日志，比如RLDP环路、地址冲突、线卡异常等异常日志。执行show run命令，核查对应设备是否存在rate-limit或者QOS等限速配置，对应限速命令会导致对应流量超出限速阈值后丢包。间隔1S执行多次show arp detail x.x.x.x / show mac address h.h.h，核查对应丢包源目IP地址在丢包的时候，有没有出现接口或者MAC变动的情况，若是出现对应MAC变动，主要核查是否存在地址冲突，若是存在接口变动，主要核查是否存在环境环路问题。如下图，明显存在MAC漂移情况。通过点4可明确对应流量经过端口，执行对应show inter g x/x，主要关注以下两个参数：接口是否存在CRC/DROP数值增长情况，若是，主要核查物理接口以及物理链路是否存在异常。接口peak时间是不是丢包时间，若是，主要核查丢包的时候是否存在流量跑满情况。执行show cpu-protect核查对应CPP，明确是否存在异常的CP……

SE_You 2024-12-24

13 0 0
交换机

锐捷S7805C下联终端ping服务器丢包

一、故障现象 S7805C交换机下联终端 ping监控存储服务器一直丢包。网络拓扑如下：二、设备型号设备型号：S7805C 软件版本：RGOS 12.3(1)B0202 三、故障排查步骤先确认丢包点；在丢包设备上检查丢包原因；四、故障排查过程通过acl计数确认丢包位置在7805C的下联口；发现交换机下联G1 /11接口下丢包逐渐增加；检查没有环境问题，无cpp和nfpp丢包以及环路；检查发现接口利用率几乎占满，初步判断是接口带宽不足（流量过大）导致的丢包； show queue-counter interface查看的确存在mmu丢包；综上所述：在最初方案设计的时候是可以正常使用的，后续客户做了业务调整，改变了业务环境，导致流量过大引发的mmu丢包。由于客户做了业务变更引发问题，归属于客户原因。五、解决方案将千兆口换成万兆口；将接口做成聚合口； Trunk口可以做vlan修建；将接口下的部分业务迁移到其他接口；

SE_You 2024-12-23

7 0 0
交换机

锐捷N18007下联终端跨网段ping丢包

一、故障现象描述场景拓扑图1：故障拓扑现象描述如上图所示，赛事测试机10.80.0.117同网段ping自己的网关10.80.0.254、跨网段ping10.60.10.119和10.255.0.50存在丢包，小包丢包概率较低，大包比如3000字节丢包明显，现场ping97个测试结果为丢包7个，终端只收到了90个包。二、故障排查分析使用终端10.80.10.117 ping 服务器10.255.0.50复现故障时，在核心交换机的上下联口开启ACL计数，发现ping的问题在核心交换机处被丢弃。图2：ACL计数配置图3：下联口调用配置图4：上联口调用配置终端长ping97个包，在丢包7个后停止，观察ACL计数结果为下联口down-in有收到291个，上联up-out只有发出去270个，其中21个再交换机内部被丢掉（因大包分片，字节好数据经过计算与转终端的多少有差异，但只要观察收发情况即可）。图5：ping结束计数统计检查交换机故障期间对应日志，异常日志有检测到环路loop日志和2/FE1卡内联口震荡日志：图6：环路检测异常日志图7：FE卡内联口异常日志如上述图6所示，核心有检测到环路但随机被执行了的违例处理，结合现场通网段ping测试一直无丢包，仅是跨网段访问，同时设备的CPU和内存均处于正常水平，排除环路可能。故障疑点聚焦于2/FE1和2/2槽位线卡，同时因现场AGG13口只有一个成员口可用，中午时间将可用的Fo2/2/49线路迁移到其他板卡测试，使用3000字节大包继续进行ping网关和服务器测试，ping780个包后，发现网关无丢包，服务器丢1个包，截图如下，说明判断的疑点方向正确，问题点在2/FE1或2/2上：日志有报内联口震荡，且设备无CPU高和CPU丢包情况，问题点大概率发生在硬件芯片层面，使用ssa命令分别检查2/FE1和2/2线卡，发现2/FE1存在奇偶校验（SER Parity）关键报错，而2/2卡无异常报错，2/FE1卡奇偶校验报错见下图8所示，2/2卡无……

SE_You 2024-12-20

10 0 0
交换机

锐捷N18012 终端ping交换机偶发丢包

一、故障现象描述网络拓扑：故障现象：终端 ping SDN_18K的地址会偶发丢包。设备型号：N18012 设备版本：N18000_RGOS 11.0(4)B58P2 二、故障排查分析从现场的抓包来看，SDN_18K交换机在丢包时间段网络中会出现大量的ARP广播报文。通过抓取SDN_18K底层信息，针对存在大量arp广播现象进行分析发现： SDN_18K交换机先收到终端10.64.4.160请求终端10.64.4.52的arp请求，由于super vlan启用了arp代理功能，此时SDN_18K会做代理应答，会以arp reply报文的形式回复10.64.4.160这个终端的mac为SDN_18K的mac( 300d.9e73.e950)，访问10.64.4.52将流量时候目的mac则为300d.9e73.e950。按照正常报文处理逻辑，10.64.4.160收到SDN_18K的arp代理应答完成后，则是进行正常的IP数据包转发通信，但是通过现场收集的信息进行分析，10.64.4.160再次发了一份ARP应答报文。交换机收到10.64.4.160的ARP应答报文，要将该应答报文转发到目标地址10.64.4.52，此时交换机查看10.64.4.52终端的ARP表项并未携带subvlanID(未携带subvlan id的原因是10.64.4.52不在线,只有静态arp表项、未有mac地址表项)。交换机会直接将应答报文在supervlanID4094发出，到快转后桥组件，桥组件通过MAC地址表寻找终端的MAC地址发现没有对应的MAC地址表后，找出口失败会在supervlan下的所有subvlan进行广播。由于现场交换机上的supevlan下有3000+的subvlan，导致交换机收到该arp的reply报文会在同时发3000+的arp广播报文出。从现场的DEBUG来看，该终端是每秒会发送2个的ARP应答报文到交换机，这样会让交换机在某个时间节点发出6000数量的ARP广播报文。我司交换机EFMP快转处理数量在3W左右，ARP一个泛洪报文占用了快转1/5的处理性能，加上交换机处理其他正常报文也会消耗EFMP组件性能，就导致交换机概率出现丢包情……

SE_You 2024-12-19

7 0 0
交换机

锐捷S57H 直连丢包以及转发丢包

一、故障现象描述故障拓扑如下，客户现网S57H2下面的业务上网卡顿，排查过程发现中心交换机上联S53E下联口ping下面的S57H2的上联口存在丢包。二、故障排查分析环路疑点分析完成，设备上下联三层和ACCESS互联，无TRUNK端口互联，ACCESS有开启防环策略，未发现异常环路日志。查看NFPP发现存在大量的TE1/0/51和TE2/0/51存在攻击告警，如下图有attack日志、scan和dos日志，时间与张点吻合，不排除攻击的可能：查看CPP发现ICMP存在大量的drop，且计数不断的增长，与故障吻合,暂不考虑攻击的情况，继续对设备进行排查。检查端口的丢包情况，发现部分端口存在LOSS，与故障时间吻合：底层show C显示UCQ DROP，证实设备确实存在缓存丢包性能不足问题：三、故障根因说明网络存在攻击，业务流量大设备性能不足。四、故障解决方案网络攻击问题：需要出口安全设备进行对应的IP封堵。业务流量超过设备性能问题：该设备负责核心节点业务转发，建议更换高性能的框式设备解决。

SE_You 2024-12-18

7 0 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下用户流……

SE_You 2024-12-17

8 0 0