NS宇宙的古早内网BBS事实上已弃用,之所以未直接下线,考虑到大量历史技术文档还在其上,且仍有学习价值。我倒是一直为之添砖加瓦,将之用作技术文档备份基地。

上个月2022年大型那啥活动期间,该BBS临时下线。活动结束后才重新上线,却发现它经常挂掉,外在表现是浏览器访问时无响应,或提示Oops错。每次LCG重启OS后能正常一阵子,几分钟后再次挂掉。寻思之前正常了十八年,不可能是BBS本身有啥幺蛾子,找LCG要了管理员密码,远程登上去排查。

BBS的WEB部分在A机,数据库在B机。LCG之前简单排查过,每当BBS挂掉时,从A机无法访问B机1433/TCP。我RDP到A机,简单看了一下CPU、内存、硬盘使用率,无异常峰值。"telnet B 1433"确实不行,"ping B"也不行,这就有点奇怪了,一般来说B不大可能单独封禁入站ICMP。看A机上有Wireshark,准备抓包,顺带下载sysinternals工具集,却发现A机网速异常缓慢。"arp -a"看了一眼,临时起意"arp -d B",重新"ping B",意外发现通了,然后B机1433/TCP可达。此刻BBS已能正常访问,无需重启A机。虽然没有Wireshark抓包,也能猜个大概,可能是A机ARP缓存被污染,其中的B条目MAC地址不对。这只是猜测,我没有B机管理员账号。决定等几分钟,待其再次挂掉时重新检查A机ARP表中B条目,检查B的MAC地址是否出现过异常变动。

几分钟后BBS如期而挂,RDP上去检查A机ARP表,表中B的MAC地址未出现异常变动。至此判定问题不在A机,而是B机的ARP表出幺蛾子了。我这么想的,"arp -d"之后ping,会触发ARP请求,这种报文会刷新B机ARP表;重启A机后从A机访问B机,也会触发ARP请求,同样会刷新B机ARP表。B机ARP表中A条目正常时,BBS正常;B机ARP表中A条目异常时,A机与B机之间IP层通信受阻,外在表现包括但不限于ping不通、1433/TCP不可达。该猜测解释得通现有现象,但我没有B机管理员账号,联系LCG去检查B机ARP表。

LCG在B机ARP表中果然发现异常A条目,表中A的MAC不是A的,是一个未知MAC,我的猜测得到确认。LCG去交换机上查了该未知MAC,对应到另一台设备,后者被错误配置了A机IP。换句话说,此处存在IP冲突,但不知为何A机本身未告警,那台设备亦未告警,可能与网络拓扑相关,但我不是信管部的,不清楚具体情况。这个IP冲突致使B机ARP表中A条目不稳定,有时指向A机,有时指向另一台设备。

找到终极原因之后,解决之道显而易见,给另一台设备配置其他IP。

没啥高深技术卷入其中,只是觉得排查过程值得记一笔。以前写过另一篇类似风格的。