-
锐捷路由器设备异常重启
一、故障现象 设备反复重启，或在启动过程中就打印堆栈信息然后又重启。 二、组网拓扑 无 三、可能原因 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 -
CentOS7系统双网卡环境下添加静态路由的几种方法
如下拓扑图所示(点击图片查看清晰大图) 场景简单描述一下： CentOS7系统为双网卡的网络环境 1)ens33:10.20.10.93/23是外网网卡，也是默认网卡，网关10.20.10.1 2)ens37:172.16.10.25/24是内网网卡 用ip addr 、ifconfig、route -n查看网络及路由信息，信息如下 现在要添加一条静态路由，实现这台CentOS7机器能访问整个内网172.16.0.0/16网段,需要在后台添加静态路由 下面介绍添加静态路由的几种方法 1、route add -net命令手动添加 route add -net 172.16.0.0 netmask 255.255.0.0 gw 172.16.10.1 dev ens37 并写入到开机启动项中 echo "route add -net 172.16.0.0 netmask 255.255.0.0 gw 172.16.10.1 dev ens37" >>/etc/rc.local 并reboot重启后验证开机后静态路由是否生效 当然命令中也可以去掉最后dev ens37 route add -net 172.16.0.0 netmask 255.255.0.0 gw 172.16.10.1即可 2、nmtui图形化界面添加 命令行输入nmtui(若没有nmtui命令，需要yum install net-tools安装) 在Routing这一栏中编辑 添加一条静态路由 目录网段172.16.0.0/16 Next Hop下一跳172.16.10.1然后保存 添加好静态路由后，保存退出 接下来重启网络服务service network restart生效 route -n查看静态路由是否添加成功 其实nmtui添加完静态路由会在/etc/sysconfig/network-scripts/目录在生成route-IFACE(网卡名)的路由配置文件，如下截图所示 3、第三种方法，手动在/etc/sysconfig/network-scripts/目录下创建一个 新建route-IFACE(网卡名)的路由配置文件 每三行定义一条路由（其中#代表序列添加的第几条）ADDRESS#=TARGET ADDRESS0=172.16.0.0 NETMASK#=mask NETMASK0=255.255.0.0 GATEWAY#=GW GATEWAY0=172.16.10.1 如下图所示, cd /etc/sysconfig/network-scripts/ vi route-ens37 添加 ADDRESS0=172.16.0.0 NETMAS……
SE_You
2025-09-28
220 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
120 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 -
锐捷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 -
锐捷RSR20-X-28 自动重启 堆栈sms_server
一、故障现象描述 RSR20-x-28，设备自动重启，版本为10.4(3b75)p3 Release（216047）。 二、故障排查分析 1、查看show log 是否有异常信息，无异常信息。 2、查看是否有死机堆栈信息，通过如下命令查看： debug sup show exception 发现设备异常重启时间点的堆栈信息，显示sms_server 三、故障根因说明 SMS_Server该模块是设备中的短信网关功能，主要用于向SNC服务器发送消息。在10.4(3b75)p3 Release（216047）该功能的任务为默认创建，在创建任务过程中，对Accept套接字的返回值未做预期判断，导致该函数返回失败（返回值：-1）的值被强制转为无符号去做一个数组的下角标，造成巨数下角标访问数组越界，导致设备重启。 四、故障解决方案 升级10.4(3b114) Release（225062）及以上版本解决该问题。
SE_You
2025-09-23
28 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
32 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
时光机
