路由器
  • 锐捷路由器设备异常重启

    一、故障现象 设备反复重启,或在启动过程中就打印堆栈信息然后又重启。 二、组网拓扑 无 三、可能原因 1、供电问题 2、死机问题 3、软件问题 4、安装不到位问题 5、硬件问题 四、排查步骤 步骤一:检查是否是供电问题 查看电源供电插座、线路是否有接触不良现象,供电电压是否不稳定。 步骤二:检查是否为死机问题 请先尝试“设备死机”章节的排查方式,若发现有“对应时间”的死机堆栈,可做相关的信息收集,反馈4008111000定位具体是硬件问题还是软件问题。 步骤三:检查是否为软件问题 方式1:尝试重新升级一个软件版本。可尝试将软件版本升级到最新版本。若升级到最新版本后,就不再重启,故可判断为设备原版本存在软件问题。 方式2:尝试空配置起机。在备份设备配置后,重启设备,在启动初始的时候按“ctrl+c”进入ctrl层,把配置文件重命名为config.bak等文件名,使得设备空配置加载,启动后若不再重启,故可判断为设备原版本存在软件问题(其中部分配置触发了该问题)。 步骤四:检查是否是安装不到位问题 尝试拔插主控引擎(对于箱式设备) 。拔插主控引擎用于排除由于主控引擎安装不到位引起的故障。 若双主控的情况下,可对换主备引擎,判断故障。 步骤五:检查是否为硬件问题 尝试更换硬件 。对于箱式设备,有备用引擎的,可以将备用引擎和主用引擎对调(redundancy forceswitch或者长按原主引擎的OFL到灯灭后拔插原主引擎)。对于盒式设备,进行整机替换。若对调以后之后不再出现故障,则原主引擎/原盒式设备可能存在硬件故障。若对调主备引擎后仍然故障,且排除了软件层面的问题,可能是机框硬件故障。 五、信息收集 信息收集命令参考 ter len 0 show ver show run show log show cpu show memory show version show version slot show environment show ip fpm counters show ip fpm statistics show ……

    SE_You 2025-09-30
    117 0 0
  • 锐捷RSR77-X 新增ENM-1QXS线卡无法正常上电起来

    一、故障现象描述 RSR77-X SIP5-X线卡3/3槽位新增ENM-1QXS子卡无法正常上电起来 二、故障排查分析 1、通过show version slot 查看对应的线卡状态为installed,说明插入的线卡没被识别到 2、查看设备对应线卡面板状态,RDY指示灯不亮,说明线卡未被正常上电 3、通过show logging查看设备日志,提示需要重启sip5-x线卡3/0 *Oct 16 20:39:42: %HPGTRB-5-LINE_CARD_EXCEPTION: Start Check module(1) notify card 3/3 fault *Oct 16 20:39:42: %HPGTRB-5-LINE_CARD_EXCEPTION: card 3/3 is in exception,reset it! *Oct 16 20:39:42: %HOTPLUG-5-DISABLE_LINE_CARD_BEGIN: Begin to disable the line card in slot 3/3. *Oct 16 20:39:48: %HOTPLUG-3-PUSH_FAIL: Push line card 3/3 failed, please reset the line card 3/0 to take effect *Oct 16 20:39:48: %HOTPLUG-5-DISABLE_LINE_CARD_OK: Disable line card in slot 3/3 OK. 三、故障根因说明 RSR77-X SIP5-X主卡搭配ENM-1QXS子卡的注意事项: ENM-1QXS该卡不支持热插拔,异常行为如下: 1、SIP5-X已启动,ENM-4XS同步启动,将原ENM-4XS拔出替换插入ENM-1QXS。 软件逻辑:ENM-4XS随SIP5-X上电,该槽位默认只支持ENM-4XS,不支持ENM-1QXS。 2、SIP5-X已启动,在空槽位插入ENM-1QXS。 软件逻辑:未初始化的空槽位,不支持ENM-1QXS上电。 以上两种情况都会导致ENM-1QXS无法使用,软件行为最终目的都是限制子卡的热拔插。 该设计的原因是因为SIP5-X的子卡都没有CPU,功能配置均依赖于SIP5-X的交换芯片。热拔插、替换卡等行为都需要修订SIP5-X的交换芯片配置,需要重启交换芯片后生效。因此对外呈现的行为就是不支持热插拔,若发生该行为就需要重启线卡。 ENM-1QXS能正常使用的行为如下: 1、与SIP5-X一起上电初始化 2、插入ENM-1QXS后,复位SIP5-X线卡,一起……

    SE_You 2025-09-29
    24 0 0
  • 锐捷RSR20X路由器设备异常重启

    一、故障现象描述 RSR20-X突然断网,设备重启 场景拓扑 不涉及 二、故障排查分析 检查是否出现死机的情况。因为没有出现断电的情况,故优先怀疑是设备出现了死机。通过debug support→show exception命令查看是否有死机堆栈。发现死机堆栈有输出 Ruijie#debug sup Ruijie(support)#show exc Ruijie(support)#show exception Exception address is 0x110000! ====================================================================== Exception Head Information Entry Number: 1 MAX Entry Number: 31 First Number: 0 Last Number: 0 ====================================================================== Time: 2024-3-16 23:40:2 size: 3365 Exception Message: System(CPU 0) Exception Occured: ExType: XTLB Miss Exception Current Thread: sms_server //注意关键字sms_server SP : 0000000033142D40 SP Start : 000000003313B480 SP End : 0000000033144FF0 CP0 Error Report Registers: Cause : 00800008 EPC : 0000000000D90F9C Status : 50008CE3 ErrEPC : 0000000033142F70 ErrCtrl : 02840000 BadVAddr : 0000000053141E68 CacheErr : 00001528 RA(r31) : 0000000000D90F64 General Purpose Registers (GPRs): 0 (r00) : 0000000000000000 s0(r16) : 0000000000000000 AT(r01) : 0000000050008CE0 s1(r17) : FFFFFFFFFFFFFFFF v0(r02) : 0000000000000000 s2(r18) : 000000000000840B v1(r03) : 0000000053141D3C s3(r19) : 0000000000000080 a0(r04) : FFFFFFFF80000000 s4(r20) : 000000000000000B a1(r05) : 0000000000000000 s5(r21) : 0000000033142F70 a2(r06) : 0000000000000000 s6(r22) : 0000000000000000 : 000000 a3(r07) 000000840B s7(r23) : 0000000000000001 a4(r08) : ……

    SE_You 2025-09-26
    121 0 0
  • 锐捷RSR7704 设备异常重启

    一、故障现象描述 RSR7704路由器突然自动重启业务中断,重启5分钟后业务恢复。 场景拓扑 不涉及 二、故障排查分析 检查设备重启时间,通过show version命令查看System start time设备启动时间,发现时间和客户反馈的设备重启时间对得上,确实存在设备重启的情况。 检查故障时候的日志。发现客户未配置logging file flash命令将日志记录在flash,导致重启后没有相关重启前的日志可以回溯。 检查死机堆栈。通过在主控和线卡下,debug sup→show exception,发现没有对应时间的死机堆栈,还无法判断存在软件问题。 确定故障时候的电源情况。发现除了7704,其他设备没有重启,暂时排除电源问题。 再次检查设备show ver,发现主备引擎之间的系统时间存在主备配置不同步的现象,导致系统时间不一致,差距大。主备配置不一致会导致主备控均复位,也就是设备重启的现象。 三、故障根因说明 该问题判断为主备配置不一致导致主备控均复位导致线卡也异常复位的设备重启现象,从而影响业务。该问题定位为软件问题,可以升级最新版本进行优化。 四、故障解决方案 升级至10.4(3b95)p2 Release(234137)最新推荐版本。

    SE_You 2025-09-25
    52 0 0
  • 【转载】loopback接口、router ID详解

    目录 loop back接口简介: loopback接口应用: router id 简介: 选举规则: loop back接口简介: loopback接口是一种纯软件性质的虚拟接口。loopback接口创建后物理层状态和链路层协议永远处于up状态。loopback接口可以配置ip地址,为了节约ip地址,系统会自动给loopback接口的ip地址配置32位的子网掩码。loopback接口下也可以使用路由协议,可以收发路由协议报文。 注意:  在loopback接口上只能配置32位的子网掩码。 loopback接口应用: 将loopback接口地址设置为该设备产生的所有ip数据包的源地址,因为loopback接口地址稳定且是单播地址,所以通常将loopback接口地址视为设备的标志,在认证或安全等服务器上设置允许或禁止携带loopback接口地址的报文通过,就相当于允许或禁止某台设备产生的报文通过,这样可以简化报文过滤规则。但需要注意的是,将loopback接口用于源地址绑定时,需确保loopback接口到对端的路由可达,而且,任何送到loopback接口的网络数据报文都会被认为是送往设备本身的,设备将不再转发这些数据包。  另外,因为loopback接口状态稳定(永远处于up状态),该接口还有特殊用途,比如,在动态路由协议里,当没有配置router id时,将选取所有loopback接口上数值最大的ip地址作为router id。 详解: 路由器环回接口(loopback)详解_清尘大哥的博客-CSDN博客_loopback Loopback接口的主要作用及Loopback端口配置_JackLiu16的博客-CSDN博客_loopback接口怎么配置 回环接口(loop-back/loopback)_MoaKap的专栏-CSDN博客_回环接口 -------------------------------------------------------------------------------------------------------------------------------------------------- router id 简介: 格式与IP地址相同,表示的是启用了OSPF协议的路由器的名字。格式虽然是IP地址形式……

    SE_Zhang 2025-09-25
    227 0 0
  • 锐捷RSR20X 死机,重启后恢复

    一、故障现象描述 RSR20X突然出现业务中断,没有接线的接口灯也亮,无法自动恢复,最后通过重启设备后业务恢复。 场景拓扑 不涉及 二、故障排查分析 查看是否存在死机信息。通过debug sup→show exception,发现有对应断网时间点的死机堆栈信息。死机堆栈信息提示sms_server。SMS_Server该模块是设备中的短信网关功能,主要用于向SNC服务器发送消息。在10.4(3b75)p3,Release(216047)该功能的任务为默认创建,在创建任务过程中,对Accept套接字的返回值未做预期判断,导致该函数返回失败(返回值:-1)的值被强制转为无符号去做一个数组的下角标,造成巨数下角标访问数组越界。 三、故障根因说明 SMS_Server该模块是设备中的短信网关功能,主要用于向SNC服务器发送消息。在10.4(3b75)p3,Release(216047)该功能的任务为默认创建,在创建任务过程中,对Accept套接字的返回值未做预期判断,导致该函数返回失败(返回值:-1)的值被强制转为无符号去做一个数组的下角标,造成巨数下角标访问数组越界。 四、故障解决方案 升级官网最新版本解决。

    SE_You 2025-09-24
    39 0 0
  • 锐捷路由器内存利用率高排查方法

    一、故障现象 RSR路由器内存利用率高 二、组网拓扑 无 三、可能原因 1、检查是否属于正常现象 2、检查是否内存泄漏 四、排查步骤 步骤一:检查设备内存是否已耗尽 1)登陆到设备,获取内存信息(如下2种方法任选一种即可)。 Console口连接设备,键盘输入后,SecureCRT或超级终端上是否存在回显,如有回显,登陆设备并执行show memory (2次) Telent或SSH远程连接并登陆到设备,执行Show memory (2次) 2)查看详细内存占用情况。如果console口输出如下结果之一,则证明内存已经被泄露完毕,系统无法正常申请内存,通常此时设备已经不能正常工作,业务中断。 not enough memory! cli execute fail! *Sep 6 08:54:14: %SCHED-0-NOSTACK: Could not allocate 40960 bytes for stack from memory. 由于已经影响客户业务,且客户需要立刻恢复业务,无法提供信息收集的情况下,可直接重启设备,观察是否能够恢复。 如果执行show menory,可以正常输出结果,则说明还有一定内存,可维持系统正常运行。 示例: Ruijie#show memory System Memory Statistic: Free pages: 2898 watermarks : min 433, lower 866, low 1299, high 1732 System Total Memory : 128MB, Current Free Memory : 14580KB Used Rate : 89% 遇到上述内存利用率较高(例如达到70%以上),但设备仍然可以正常工作,或内存利用率低于70%,但担心设备存在异常的,则继续下面的排查步骤。 步骤二:检查是否属于正常现象 由于功能变化,例如单播路由条目增加、组播表项增加等其他功能调整均会导致内存一定程度增加,但此类增加通常比较平稳,内存利用率不会大幅增长,例如1K路由约占用2M内存,由于网络扩容改造,设备多学习到了1K条路由,会导致内存减少2M左右,属于正常现象,并非故障。 也可通过show memory命令的输出,观察Free Memory的变化。如……

    SE_You 2025-09-22
    47 0 0
  • 锐捷RSR30X IOWAN场景 grpc进程CPU高

    一、故障现象描述 RSR30-X路由器存在grpc进程CPU高的情况 二、故障排查分析 故障前客户侧控制器执行了8口移动线路的变更操作,对应操作将会对ipsec配置进行修订,grpc下发的内容如下图日志所示(如下信息重复出现): 检查配置发现路由器上除了控制器下发的Gi0/0/8的crypto map之外,还有一个Gi0/0/8_1手动配置的crypto map。这两个crypto map都调用了transform-set Gi0/0/8_1,导致控制器下发删除crypto map Gi0/0/8和transform-set Gi0/0/8_1的时候,由于crypto map Gi0/0/8_1也调用了相同的transform-set,删除transform-set失败。因此,路由器无法完成控制器下发的操作,故持续循环此grpc过程,导致grpc进程cpu持续高。 上述的软件处理逻辑如下图所示: 控制器向设备下配置,等待15s get设备响应。若没有响应,认为下配置失败,重新下。 设备处理完命令告诉控制器失败或成功 三、故障根因说明 由于设备存在手工配置的crypto map,和控制器下发的crypto map调用了相同的transform-set,导致控制器删除transform-set失败。因此,控制器持续通过grpc下发对应配置,导致CPU高。 四、故障解决方案 解法方式:通过删除手工配置的crypto map Gi0/0/8_1。

    SE_You 2025-09-19
    33 0 0
  • 锐捷RSR77-X 高校场景 dhcp进程CPU利用率高

    一、故障现象描述 RSR7708-X 设备CPU利用率达到99%、每次持续1分钟左右、业务未出现异常 二、故障排查分析 确认故障信息:设备上查看历史日志记录,每次CPU告警<dhcpd_task>进程占用CPU利用率占用最高、每次出现CPU高时间间隔均为1小时50分钟; 查看CPU高的时候CPU利用率情况、dhcp6_main进程占用40%左右; 三、故障根因说明 该问题原因是存在dhcp模块监听流转发模块时的处理不当(代码级监听,和是否配置dhcp无关),当设备上出现中断信号非常多的情况时,会导致dhcp抢不到CPU而发生消息事件积压;中断信号处理完成后、dhcp处理堆积的消息事件时会占用较多的cpu,堆积信息事件处理完成后恢复正常的cpu使用;整体体现为系统cpu使用率突然飙升,之后再慢慢恢复正常,整个过程持续时间约为1分钟。可以简单理解为dhcp模块出现空转现象,这种空转现象不影响设备的正常业务使用。 四、故障解决方案 升级软件版本至RSR77-X_10.4(3b98)p3_R235360及以上版本解决。

    SE_You 2025-09-18
    48 0 0
  • 锐捷CPU-snmpd 进程高

    一、故障现象 路由器CPU snmpd进程利用率高 二、组网拓扑 无 三、可能原因 1、SNMP进程占用CPU过多,该进程cpu占用率高的话,通常为大量SNMP报文送CPU或SNMP获取设备某MIB节点占用CPU较多 四、排查步骤 步骤一:通过命令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 ...... 13 0.00% 0.00% 0.00% snmpd 进程解释: snmpd :snmp协议进程。 步骤二:配置SNMP关联ACL只允许合法的SNMP服务器访问。 配置ACL: ip access-list standard trust-snmp 10 permit 10.249.252.0 0.0.0.255 20 permit 172.18.252.0 0.0.0.255 将ACL应用到SNMP: Ruijie(config)#snmp-server community ruijie rw trust-snmp 如果这台设备本身没网管需求,可以把SNMP功能关闭。关闭SNMP代理:no enable service snmp-agent //关闭SNMP会导致网管无法管理设备!!! 通过以上操作后,观察CPU利用率经过一段时间是否恢复。如果无法恢复,请直接跳转到信息收集章节,收集信息,拨打4008111000 五、信息收集 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 六、总结与建议 SNMP进程占用CPU过多,通常为大量SNMP报文送CPU或SNMP获取设备某MIB节点占用CPU较多。

    SE_You 2025-09-17
    36 0 0