路由器
  • 锐捷RSR7708-X ospfd导致CPU利用率为99%

    一、故障现象描述 客户反馈路由器在使用过程中断网一次,重启后网络恢复,但是网速很慢,登录设备查看时,发现路由的CPU利用率一直都是99%,且在输入命令时路由器响应速率很慢 场景拓扑 二、故障排查分析 查看CPU利用率的具体情况,发现进程较高的两个分别为tnet和ospfd 查看设备日志,发现设备中有大量的LLDP邻居震荡日志,使用no lldp enable 命令关闭LLDP功能,关闭后CPU利用率仍然为99% tnet作为IPv4进程转发进程,该进程较高可能是由于收到攻击,查看设备配置,发现已配置防攻击保护、全局ACL过滤攻击也以开启,未发现异常,由于客户现场子接口数量较多(1500多个),并未查看各个接口下流量统计 ospfd进程为OSPF协议守护线程,因此首先排查是是否network网段过多导致的CPU过高,发现并未出现network 0.0.0.0 之类的宣告方式 排查ospf邻居是否过多或震荡,发现邻居数量只有3个,且未频繁震荡 show ip ospf database | include 3600 查看否存在lsa 在频繁老化刷新,发现并未出现 查看SPF是否震荡,发现也在正常计算范围内 后查看ospf报文的收发情况,发现有大量的ospf发送,由于该设备有1500多个子接口,每个接口发送和接受大量的ospf报文导致CPU过高 三、故障根因说明 该故障是由于设备只使用某几个接口建立ospf邻接关系,但是设备上其他1500多个子接口上未关闭ospf发送和接受功能,导致每个接口都接收大量的ospf报文,导致ospfd进程使用率过高,而ospf报文是送至路由器本地处理,不走快转,因此tnet进程使用率过高,两个进程导致CPU利用率99%. 四、故障解决方案 将不需要接受ospf的报文的邻居设置为passive interface   passive interface:当一个接口被配置为被动接口时,它将不再主动发送Hello消息。相反,它将只监听来自邻居发送的Hello消息,并对其进行响应。 ……

    SE_You 2025-09-16
    45 0 0
  • 锐捷RSR08M路由器CPU利用率升高问题处理群 副本

    一、故障现象描述 某客户使用我司RG-RSR-08M路由器作为下联汇聚设备。在使用过程中设备出现CPU周期性出现峰值问题。 二、故障排查分析 查看高峰期CPU利用率发现,scripc、scripc_rx、ripd、ospf6d等进程利用率较高,使得整机CPU利用率高达50%,详细情况如下图所示: 内部按照现场配置,版本,路由邻居个数和路由表项1:1搭建环境测试,最终测试出了现场类似的故障现象,分析发现当前设备CPU在1小时50分钟会出现系统CPU整体利用率升高,持续3分钟左右后恢复正常。内部复现结果如下: PS:进程含义解释 1.scipc:主控给线卡下发配置的进程 2.scipc_rx:主控从线卡获取信息的进程 3.fpm-age-task:是流表老化进程。 4.ripd:rip路由计算进程。 5.ospf6d:ospfv3路由条目计算进程。 三、故障根因说明 经过芯片特性分析以及内部复现验证,当下版本,每1小时50分钟会出现硬件中断集中并发处理的现象,届时会短暂导致系统CPU整体利用率升高,持续3分钟左右后恢复正常。经过研发评估,因此判断这种周期性CPU升高,对业务无影响。 四、故障解决方案 当前属于正常现象,在后续RSR08M版本中进行优化。

    SE_You 2025-09-15
    36 0 0
  • 锐捷CPU-nsmd/ripd/ospfd/bgpd/isisd 进程高

    一、故障现象 路由器CPU nsmd/ripd/ospfd/bgpd/isisd进程利用率高 二、组网拓扑 无 三、可能原因 1、以上这些进程都和路由协议强相关,在路由协议发生震荡时,特别是网络比较庞大的情况下,需要消耗大量的CPU计算和收敛。 四、排查步骤 步骤一:通过命令show cpu查看进程cpu利用率。 Ruijie#sho cpu ======================================= CPU Using Rate Information CPU utilization in five seconds: 0% CPU utilization in one minute : 0% CPU utilization in five minutes: 0% NO 5Sec 1Min 5Min Process 0 0% 0% 0% LISR INT 1 0% 0% 0% HISR INT ...... 60 0.00% 0.00% 0.00% nsmd 61 0.00% 0.00% 0.00% ripd 62 0.00% 0.00% 0.00% ospfd 63 0.00% 0.00% 0.00% ripngd 64 0.00% 0.00% 0.00% ospf6d 65 0.00% 0.00% 0.00% bgpd 66 0.00% 0.00% 0.00% isisd 进程解释: nsmd:网络服务模块,管理接口表与路由表,为协议模块与底层模块之间提供各种信息的交互。如接口UP/DOWN、路由添加删除等等,因此,nsmd线程处理的东西很多,比如接口创建/删除、VRF绑定/解绑定、接口UP/DOWN、路由震荡等等,都有可能导致nsmd线程占用大量的CPU,这个时候只能结合其他系统信息才能具体分析了。 ospfd/ospf6d:OSPF协议守护线程/ OSPFv6协议守护进程 ripd/ripngd:RIP协议守护线程/ RIPng协议守护进程 bgpd:BGP协议守护进程 isisd: ISIS协议守护进程 步骤二:查看是否有动态路由协议频繁重新协商的情况。 查看是否存在日志不断打印信息: *Aug 9 10:26:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet 0/24, changed state to up. *Aug 9 10:26:20: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1-GigabitEthernet 0/24 from Down to Init, HelloReceived. *Aug 9 10:26:50: %OSPF-5-ADJCHG: ……

    SE_You 2025-09-12
    24 0 0
  • 锐捷CPU-vty_connect 进程高

    一、故障现象 路由器CPU vty_connect进程利用率高 二、组网拓扑 无 三、可能原因 1、telnet远程登入线程出错。 四、排查步骤 步骤一:通过命令show cpu查看进程cpu利用率。 Ruijie#sho cpu ======================================= CPU Using Rate Information CPU utilization in five seconds: 0% CPU utilization in one minute : 0% CPU utilization in five minutes: 0% NO 5Sec 1Min 5Min Process 0 0% 0% 0% LISR INT 1 0% 0% 0% HISR INT ...... 84 0.00% 0.00% 0.00% vty_connect 进程解释: vty_connect模块初始化线程,用于创建\断开vty连接; 步骤二:telnet线程出错,可尝试停止在telnet上执行的操作命令,等待一段时间确认CPU利用率是否下降。 步骤三:如果vty_connect CPU占用未能下降,可以通过清除对应vty进程尝试解决;比如执行show run、show 命令都会对CPU有所影响,可以在信息收集完一段时间检查cpu利用率是否下降。 1)通过show users查看当前vty用户 2)通过执行clear line vty xx将vty连接都清除掉。 步骤四:通过show log 查看是否有异常用户连接设备的失败日志 可以通过acl过滤非法终端Telnet登入设备进行观察 五、信息收集 show run show memory show version show cpu show users show log show memory show arp show ef-rnfp all //间隔10S,收集3次 Show ip fpm statistics sh ip fpm users show ip rou summary show ip ref route statistic sho ip ref adjacency show ip fpm st show ip fpm count show core | b Buff debug support show except pcie show show skb show task show efb 六、总结与建议 vty_connect模块初始化线程,用于创建\断开vty连接,一般是telnet远程登入线程出错导致。

    SE_You 2025-09-11
    15 0 0
  • 锐捷CPU-rl_con 进程高

    一、故障现象 路由器CPU rl_con进程利用率高 二、组网拓扑 无 三、可能原因 1、show 命令打印较多。 四、排查步骤 步骤一:通过命令show cpu查看进程cpu利用率。 Ruijie#show cpu ======================================= CPU Using Rate Information CPU utilization in five seconds: 0% CPU utilization in one minute : 0% CPU utilization in five minutes: 0% NO 5Sec 1Min 5Min Process 0 0% 0% 0% LISR INT 1 0% 0% 0% HISR INT ...... 146 0.00% 0.00% 0.00% rl_con 147 100.00% 99.97% 99.97% idle 进程解释: rl_con 控制台线程,用于处理命令,打印或者命令执行的进程,所执行的命令的执行函数长时间占用CPU。 步骤二:检查设备是否开启console日志打印。 比如执行show run、show 命令都会对CPU有所影响,可以在信息收集完一段时间检查cpu利用率是否下降。 可尝试关闭console口的日志输出功能,Ruijie(config)#no logging console 或限制日志的输出速率, Ruijie(config)# logging rate-limit all 10 except emergencies 五、信息收集 show run show memory show version show cpu show debug vtty 1/0 en show debug ctrl+x //退出线卡 show log show memory show arp show ef-rnfp all //间隔10S,收集3次 Show ip fpm statistics sh ip fpm users show ip rou summary show ip ref route statistic sho ip ref adjacency show ip fpm st show ip fpm count show core | b Buff debug support show except pcie show show skb show task show efb 六、总结与建议 rl_con线程一般在收集信息或调试信息操作时,将导致该线程占用CPU过多的资源。比如debug/show信息/@@@@@信息等。一般都是在打印时间段内CPU飙高,打印信息完毕后会回归正常。

    SE_You 2025-09-10
    34 0 0
  • RG RSR77-X 设备CPU printk_task进程高

    一、故障现象描述 RSR77-X 通过console登入卡、业务异常 场景拓扑 二、故障排查分析 通过show cpu查看设备CPU占用100%,其中printk_task进程占用99%以上 该进程CPU高一般原因是频繁打印日志引起,通过关闭日志(no logging on)后CPU慢慢降下 Show debug 查看未开启设备debug信息;show log查看存在大量SNMP攻击报文的打印 通过dir查看设备日志历史文件,全部被snmp攻击的异常日志占满 设备上通过ip fpm session filter 进行放通合法snmp服务器访问,阻断其他非法设备访问snmp后,开启日志未再出现snmp异常打印 三、故障根因说明 设备受到外网大量snmp攻击,设备频繁打印日志,导致设备CPU过高、业务异常 四、故障解决方案 通过流攻击保护ip fpm session filter 进行放通合法snmp服务器访问,阻断其他非法设备访问snmp解决

    SE_You 2025-09-09
    23 0 0
  • RG CPU-tnet/tnet6 进程高

    一、故障现象 路由器CPU tnet/tnet6进程利用率高 二、组网拓扑 无 三、可能原因 1、设备接口没有开启REF; 2、设备收到大量异常报文或设备受到攻击 ; 四、排查步骤 步骤一:通过命令show cpu查看哪些进程cpu利用率高。 Ruijie#show cpu ======================================= CPU Using Rate Information CPU utilization in five seconds: 54% CPU utilization in one minute : 57% CPU utilization in five minutes: 56% NO 5Sec 1Min 5Min Process 0 14% 15% 15% LISR INT 1 1% 1% 1% HISR INT 2 0% 0% 0% ktimer ....... 25 0% 0% 0% tnet6 26 39% 41% 40% tnet 进程解释: tnet:IPv4进程转发进程,有别于锐捷快速转发(IP REF)。 tnet6:即IPv6进程转发进程,和tnet类似,只是用于处理IPv6报文。 进程转发与快速转发的区别: 1、锐捷快速转发是一系列促进报文快速转发提升设备性能的机制集合,比如流机制、多线程、V-CPU等等。而进程转发是传统的、单纯靠CPU按照既定逻辑处理报文的机制,其大量消耗CPU资源,转发性能低下。 2、接口通过命令ip ref启用快速转发机制,没有启用快转的,设备就工作在进程转发模式。 3、接口启用快速转发功能(IP REF)后,还是有部分工作需要由进程转发完成: 1)所有送往设备本身,或从设备发起的数据流,比如:ftp,telnet,snmp,arp,icmp (对于穿越设备的数据走快转) 2)目的地址不可达的报文:目的地址不可达,那么快转层面会把报文交给进程处理,发送ICMP不可达等消息,也消耗CPU 3)分片报文重组:设备对于分片报文,需要重组后再转发,重组需要送CPU处理 步骤二:确认是否所有在使用的三层接口都开启快速转发功能(IP REF) 判断接口是否开启快转,由于未开启快转所有报文需要上送设备CPU处理,导致CPU利用率升高。可以通过开启设备所有接口ip ref,等待一……

    SE_You 2025-09-08
    32 0 0
  • 路由器信号测试

    路由器信号测试是评估网络覆盖范围、信号强度、稳定性及传输速率的关键步骤,可帮助定位 “信号死角”、优化路由器摆放位置或判断设备是否需要升级。以下从测试核心指标、常用测试工具、详细测试步骤、优化建议四个维度,提供完整的测试指南: 一、明确测试核心指标 测试前需了解关键评估维度,避免只关注 “信号满格” 而忽略实际使用体验: 指标名称 核心含义 合格范围(参考) 信号强度 设备接收到的路由器无线信号功率,单位为 dBm(数值越接近 0,信号越强) -30dBm~-70dBm(良好);<-85dBm(差) 信号稳定性 信号强度的波动幅度、是否频繁断连(丢包率) 波动≤5dBm;丢包率≤1%(Ping 测试) 传输速率 实际下载 / 上传速度(区别于运营商 “签约带宽”),单位为 Mbps 或 MB/s 接近签约带宽的 80%~90%(无遮挡场景) 覆盖范围 信号强度≥-75dBm 的区域范围(满足日常上网、视频通话需求) 单一路由器:家庭环境覆盖 80% 以上区域 频段表现 2.4GHz(覆盖广、穿墙强但速率低)与 5GHz(速率高、干扰少但穿墙弱)的差异 根据使用场景选择(如卧室用 5GHz,阳台用 2.4GHz) 二、选择合适的测试工具 不同工具适用于不同场景(手机端便捷、PC 端精准、专业工具深度分析),按需选择: 1. 手机端工具(适合日常快速测试) 基础工具:手机自带 “WLAN 设置”(查看信号格数,仅粗略参考); 专业 APP(推荐): Android:《WiFi 分析仪》(显示信号强度 dBm、信道干扰、频段对比)、《Speedtest》(测速率); iOS:《NetSpot》(可视化信号覆盖热力图)、《Fast》(简洁测速率 + 延迟)。 2. PC 端工具(适合精准测试) 速率测试:浏览器打开 Speedtest 官网(选择运营商节点,测下载 / 上传 / 延迟)、《迅雷》(下载热门大文件,看实际峰值速率); 信号分析:《InSSIDer》……

    SE_Yang 2025-08-30
    1.5K+ 0 0
  • 路由器故障处理解决方法

    路由器故障是家庭和办公网络中常见问题,多数可通过分步排查解决。以下将故障类型分为基础连接故障、网络卡顿 / 断连、指示灯异常三大类,提供针对性处理方案,覆盖从简单重启到进阶配置的全流程解决方法。 一、基础连接故障:设备无法联网 / 找不到 WiFi 此类故障优先排查 “物理连接” 和 “基础配置”,90% 以上可通过简单操作解决。 1. 检查物理连接(最易忽略的第一步) 先确认路由器、光猫(若有)的硬件连接是否正常,顺序如下: 光猫(宽带入口设备):若使用光纤宽带,需确保光猫指示灯中 “光信号” 为常亮绿色(不同品牌可能为蓝色),若闪烁红色 / 橙色,说明宽带线路故障,需联系运营商(如电信、联通)维修。 路由器电源:确保电源适配器插紧,路由器电源灯(通常标 “Power”)正常亮起(常亮为正常,闪烁 / 不亮可能是电源坏或路由器硬件故障)。 网线连接: 路由器 “WAN 口”(通常为蓝色,标注 “Internet”)需用网线连接光猫的 “LAN 口”(通常为黄色); 电脑 / 电视等有线设备需连接路由器的 “LAN 口”(黄色,标注 “1/2/3/4”); 检查网线两端是否插紧,可尝试更换网线(优先用 CAT5e 及以上规格)排除网线破损问题。 2. 重启设备(万能初步解决方案) 路由器长时间运行(如 1-2 个月不重启)会积累缓存,导致连接异常,重启步骤: 先断开路由器电源,等待30 秒 - 1 分钟(让电容完全放电,避免 “假重启”); 同时断开光猫电源(若有),等待相同时间; 先插光猫电源,等待 2-3 分钟(光猫需完成拨号和网络注册); 再插路由器电源,等待 1-2 分钟(路由器指示灯恢复正常后),尝试联网。 3. 排查设备端问题(排除 “不是路由器的锅”) 若仅单台设备(如手机 / 电脑)无法联网,可能是设备自身问题: WiFi 连接: 手机 / 电脑忘记 WiFi 密码后重连(避免密码输入错误); 关闭设备 “飞行……

    SE_Yang 2025-08-29
    1.2K+ 0 0
  • RG 路由器CPU-ktimer 进程高

    一、故障现象 路由器CPU ktimer进程利用率高 二、组网拓扑 无 三、可能原因 1、系统任务调度频繁或异常、定时器长时间占用 四、排查步骤 步骤一:通过命令show cpu查看进程cpu利用率。 Ruijie#show cpu ======================================= CPU Using Rate Information CPU utilization in five seconds: 0.20% CPU utilization in one minute : 0.07% CPU utilization in five minutes: 0.05% NO 5Sec 1Min 5Min Process 0 0.00% 0.00% 0.00% LISR INT 1 0.00% 0.00% 0.00% HISR INT 2 0.00% 0.05% 0.05% ktimer 进程解释: ktimer线程提供给各个模块注册定时器用的。该线程占有CPU比例高,证明有定时器长时间占用,可能部分调度存在异常。 步骤二:该进程CPU占用高,一般需要研发参与定位,请直接跳转到信息收集章节。 五、信息收集 show run show memory show version show cpu show log show memory show arp show ef-rnfp all //间隔10S,收集3次 Show ip fpm statistics sh ip fpm users show ip rou summary show ip ref route statistic sho ip ref adjacency show ip fpm st show ip fpm count show core | b Buff debug support show except pcie show show skb show task show efb 六、总结与建议 1、ktimer线程提供给各个模块注册定时器用的。该线程占有CPU比例高,证明有定时器长时间占用,可能部分调度存在异常,若出现该进程CPU高,进行收集信息反馈400处理。

    SE_You 2025-08-29
    22 0 0