-
Atlas 500 硬盘无法识别
问题描述 更新了费率后,存储设备丢失,mcu电压检测异常 处理过程 日志查看无硬盘信息 日志记录有电源跌落告警 根因 电源线接触端子磨损导致电压跌落,硬盘无法正常工作 解决方案 更换电源线,问题解决
SE_You 2022-07-1115 0 0 -
Atlas 500 修改密码提示:passwd: Authentication token manipulation error
问题描述 Atlas 500系统下修改root密码时提示:passwd: Authentication token manipulation error 告警信息 处理过程 1.执行mount检查根分区是否只读,如果根分区为ro,则执行mount -o rw,remount / 尝试重新挂载根分区为可读写模式。 2.执行:lsattr /etc/passwd和lsattr /etc/shadow,查看passwd和shadow文件的权限,两个文件权限正常。若此处显示包含i权限,则需要去掉。 3.执行df -h 查看空间使用情况,发现根分区/dev/mmcblk0p3文件系统的使用率为100%,通过删除根分区文件系统内的部分临时文件,空余出一定的空间后修改密码成功。 根因 根分区文件系统空间占用率为100%导致修改密码失败。 解决方案 删除根分区内的部分临时文件,空余出一定的空间后修改密码成功。 建议与总结 若遇到linux系统修改密码提示passwd: Authentication token manipulation error的,可做如下尝试: (1)重新挂载根分区:mount -o rw,remount / ; (2)使用lsattr /etc/shadow和lsattr /etc/passwd查看shadow和passwd的权限,若显示: —-i——–e- /etc/shadow —-i——–e- /etc/passwd 则需要使用chattr -i /etc/shadow、chattr -i /etc/passwd 命令来去掉-i 的属性。 (3)使用df -h 查看根分区是否被占满,若占满则需释放部分空间。
SE_You 2022-07-1110 0 0 -
Atlas 500 异常重启现象
问题描述 多台Atlas 500智能小站发生异常重启现象,影响现场业务运行。 处理过程 一线人员反馈现场3台设备出现异常重启现象,收集日志后,首先通过MCU日志确定系统重启的时间(MCU侧时间慢8小时,与OS日志对应时,加上8小时); 对应OS_Drivers下的kbox日志,系统重启时间与kbox记录时间吻合; 查看重启时的kbox日志,都存在out_of_memory+0x210/0x530以及oom stack堆栈相关记录,meminfo中可用内存为0Kb,确认重启原因为内存耗尽; 根据kbox日志,可确认内存溢出时的top 10进程,如下所示,其中红框标示的数据为重启时进程占用物理内存的数值,单位为pages,数据x4Kb便可计算出重启时进程占用内存的大小: xbull () ./xbull : 632146 *4Kb=2.41G java () /usr/jdk/bin/java : 77560*4Kb=0.3G mysqld ():49544 *4Kb=0.19G java () /usr/jdk/bin/java -Xms256M : 62186*4Kb=0.24G java () /usr/jdk/bin/java : 49718*4Kb=0.19G 经计算可知,以上用户的业务程序,占用了大量的物理内存(总内存4G),约3.4G; 日志中total_top_10_rss=916805(pages)表示当前top10 进程总的内存使用页(pages),乘以4Kb可换算出已使用的内存,916805*4Kb=3.5G,而total_rss_all=942163(pages)表示系统可用总页数,942163*4Kb=3.6G,可以内存基本已占用完。 另外两台设备kbox日志记录同样的问题,由此可确定,异常重启的原因是客户相关业务进程占用了内存过多导致系统内存不足,触发复位。 根因 用户运行的程序或者业务进程占用内存过大,剩余系统内存不够导致系统重启 解决方案 建议用户排查业务、分析内存占用率高的相关进程,降低内存消耗,修复内存泄漏问题 免责声明:本案例仅供参考不提供专业意见。
SE_You 2022-07-1118 0 0 -
Atlas 500 恢复web密码为默认的方法
问题描述 Atlas 500小站忘记web密码,但root可直接登录,恢复web密码为默认的方法 解决方案 1、将附件中的压缩包下载后,解压, 2、将解压后的文件上传到Atlas 500 小站 3、给脚本添加执行权限,如下图示: 4、执行脚本,web密码及可恢复为默认密码,这时再登录web界面,重新修改密码及可。 当恢复成默认密码后,如果在web对密码修改时,出现错误如下图,此时应该查询vi /etc/security/opasswd文件,将此文件清空及可。 免责声明:本案例仅供参考不提供专业意见。
SE_You 2022-07-1131 0 0 -
BIOS卡在启动选项按键提示界面
问题描述 BIOS卡在启动选项按键提示界面,如下图所示 处理过程 查看BIOS 串口日志(参见收集BIOS串口日志),搜索“ScanCode”,如果在没有外部按键输入情况下,找到多个Scancode,即有可能是串口、USB键盘、KVM键盘问题。 根因 串口设备异常。BIOS全打印日志记录大量“Scancode 0”按键输入,每一个Scancode都会发送一个中断给BIOS,BIOS的中断处理程序的优先级高于一般的BIOS初始化代码,当串口设备异常时,BIOS一直反复进入BIOS中断,所以BIOS卡在热键响应界面。 解决方案 1.依次移除物理串口、物理键盘,重启KVM键鼠,检查问题是否解决。未解决进行步骤二 2.通过SmartKit关闭Console Serial Redirect,检查问题是否解决。(注意:此操作会影响Console Serail Redirect功能 ,SOL下不能进入BIOS配置菜单;SOL下看不到POST阶段各设备Option Rom打印的提示)如还未解决进行步骤三 3.更换主板
SE_You 2022-07-093 0 0 -
A800-3000 SP331无法使用PXE功能
问题描述 配置信息:Taishan 2280 + Atlas 300 + SP331网卡 使用SP331网卡的PXE功能安装操作系统,在BIOS下无法发现SP331网卡的MAC地址。 处理过程 现网使用的BIOS版本为1.68,在BIOS的版本说明书中有写BIOS1.69及以后的版本才支持PXE功能,如下图示,建议客户升级BIOS版本为V1.69(BIOS版本说明书) 解决方案 升级BIOS版本至V169以上解决
SE_You 2022-07-045 0 0 -
Atlas800-9000服务器内存扩容后NPU驱动识别不到
问题描述 Atlas800-9000服务器在扩容内存后发现NPU驱动识别不到,服务器的操作系统为ubuntu20.04,服务器在扩容后进行了上下电的操作。 处理过程 1、检查NPU驱动以及芯片状态,执行npu-smi info上报模块初始化失败错误。 2、执行lspci | grep d801查看芯片是否在位,查询结果显示芯片都在位。 3. 执行uname -a查得当前操作系统内核版本为5.4.0-146 进入/boot/grub/grub.cfg 发现当前环境存在多个操作系统内核。 4、执行modinfo drv_pcie_host命令发现驱动对应的内核与当前内核不一致。 根因 该服务器操作系统存在多个内核版本,在客户扩容内存后进行重启时,操作系统会默认选择最新的内核版本,从而导致当前NPU驱动与最新的内核版本不一致,NPU无法被识别。 解决方案 1、将当前操作系统内核切换到NPU驱动对应的内核版本,并将此内核设置为默认启动项。 2、操作方法:切换到root用户后执行vim /etc/default/grub,在该文件下进行编辑,将GRUB_DEFAULT=0修改为NPU驱动对应的内核名称。 3、重新执行npu-smi info 命令发现驱动可以正常识别。 免责声明:本案例仅供参考不提供专业意见。
SE_You 2022-07-0224 0 0 -
IPV6经过防火墙(透明)直连ping不通
1、故障背景 场景拓扑 故障现象描述 IPV6专线经过二层交换机和透明防火墙连接到核心交换机,核心交换机配置IPV6地址后ping不通直连网关地址 2、故障排查 2.1 故障定位 环境问题 2.2 故障原因分析 1、S5700的25口是上联口,26口是下连口接防火墙,防火墙下联是核心,IPV6在核心交换机的三层口配置,防火墙是透明模式 2、防火墙上没有放行IPV6策略,远程协助用户配置后还是ping不通V6网关地址 3、防火墙上抓包查看v6的ping包已经发出去了,但是没收到回报,从S5700上镜像抓包发现g0/26口没有发送reply报文 4、查看二层交换机S57收发的报文进行对比,存在差异,S57发出去的报文源MAC地址是核心交换机的,目的MAC是专线对端,但是对端会包的目的MAC却是S57的MAC,S57收到的正常报文目的MAC应该是和核心交换机的MAC地址才对。 综上判断是S5700交换机收到专线的reply包后没有转发给防火墙,且收发包存在MAC不一致现象。 3、故障解决方案/规避方案 清除专线对端设备的IPV6neighbor 或者等待专线对端设备的邻居表老化重新学习MAC 以上两种方式再重新学习邻居后可解决问题,最终IPV6可达
SE_You 2022-06-1610 0 0 -
全新NGFW ONC引流方案故障处理案例
1、故障背景 场景拓扑 现网拓扑和业务说明如下: 整体方案采用INC ServiceChain引流方案,模式为透明模式(no sw+no ip)模式。防火墙采用路由模式虚拟连接对方法。 故障现象描述 开启INC的业务编排,对业务进行引流到防火墙后,业务不通。 2、故障排查方法 2.1故障定位 此故障为硬件问题,是由于防火墙NP芯片故障导致。 2.2故障原因分析 1、 定位故障点 防火墙进行sniffer抓包,现场并未抓取到报文,怀疑是引流交换机问题。 防火墙抓包命令:diagnose sniffer packet any ‘host x.x.x.x’ 4 l 如果有抓到报文,但没有进行转发,可确定是防火墙问题,可结合debug功能判断是什么原因导致的丢包。 diagnose debug enable //开启debug diagnose debug flow filter addr x.x.x.x //过滤x.x.x.x的地址相关debug信息 diagnose debug flow trace start 10 //打印10条debug信息 如果没有抓取到报文,大概率是引流交换机方面的问题。 2、查看INC和交换机配置,并未发现问题 3、查看INC下发的流表 使用show of flow 查看流表下发情况,参数是否正确以及count值是否有变化。如果相应的count字段的数值有不断增加,说明引流成功。 获取的其中一个流表如下: {table="0", duration_sec="177", priority="1500", flags="0x0",idle_timeout="0", hard_timeout="0", cookie="0xe51efb3520000",packet_count="10",byte_count="1298".match=oxm{in_port=“1",eth_type="0x800",ipv4_src=“30.7.0.0",ipv4_src_mask="255.255.255.0"}instructions=[apply{acts=[set_field{field:eth_src=“00:d0:f8:22:33:e5"}, set_field{field:eth_dst="1a:11:11:11:13"}, output{port=“2"}]}]} 相关字段解析: 1) duration_sec="177" 表项存在的时间 2) priority=“1500”:该流表的优先级,越大越优先。 3) ……
SE_You 2022-06-1431 0 0 -
全新NGFW-LDAP认证故障处理案例
1、故障背景 场景拓扑 故障现象描述 背景描述:外网员工使用SSLVPN拨入内网,VPN拨号的账号密码需要到服务器上做认证,防火墙通过LDAP将客户端的账密发送到服务器验证,验证通过即可拨入VPN。 故障现象:使用本地账号密码可以认证成功,但是通过LDAP认证失败。 2、故障排查 2.1故障定位 原因:用户提供的防火墙查询账号密码错误,以及账户超期导致LDAP认证失败 2.2故障原因分析 1、对比服务器上的根,OU,containers,Group,在防火墙上设置对应属性,这些属性只能在命令行配置,配置如下图: 2、防火墙上有测试LDAP认证的命令,命令如下,如图防火墙上测试提示失败,说明防火墙的LDAP配置参数可能有误。 diagnose test authserver ldap <LDAP server_name> <username> <password> 3、通过以下命令可以查看LDAP认证过程,debug显示内容如下,标注的地方可以看出认证错误的原因分别是账号密码错误和账户超期导致认证失败。 # diagnose debug application fnbamd –1 # diagnose debug enable [1148] fnbamd_ldap_recv-Response len: 104, svr: 192.168.1.10 [829] fnbamd_ldap_parse_response-Got one MESSAGE. ID:1, type:bind [851] fnbamd_ldap_parse_response-Error 49(80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839) <----- 这两个提示信息表示LDAP 身份认证无效,data52e一般代表账号密码错误 [864] fnbamd_ldap_parse_response-ret=49 [753] __ldap_stop-svr 'AD_LDAP' [182] fnbamd_comm_send_result-Sending result 1 (error 0, nid 0) for req 237259384 authenticate 'user1' against 'AD_LDAP' failed! [860] fnbamd_ldap_send-sending 116 bytes to 192.168.1.182 . . . [764] fnbamd_ldap_parse_response-Got one MESSAGE. ……
SE_You 2022-06-1230 0 0