故障描述：（某银行总数据中心）接客户电话：“音频控制终端出现故障，连接网线就会死机！”
到现场后了解情况，2024.4.25起开始报障，开机后死机，终端无法获取地址。现场有个人小型路由器，连接后正常。同网络下pad可以控制音频终端。故排除音频终端与链路物理故障。核实同事近期没有进行相关变更，随后我查看设备连接及网络配置。大致如下图：
音频终端接口为access263。音频接入与楼层接入互连access263。楼层接入双上连汇聚。汇聚之间做的链路聚合，汇聚上起DHCP服务器
DHCP配置
查看交换机日志发现25号设备开机后，日志一直显示UP\DOWN。DHCP静态绑定的mac就是音频终端。那么163.21的地址应该是音频终端要获取的。现在就是要搞清楚为什么没有获取到地址。
与同事沟通，如下
将静态绑定mac换成我电脑，将我电脑连接音频交换机，DHCP自动获取地址发现能够拿到地址。故排除网络设备配置问题。
额……终端没问题，链路没问题，配置没问题。好好好，都没问题是吧，是我的问题？那我走？
哈哈哈哈哈，开个玩笑。思索片刻，启动wireshark，让同事恢复配置。端口镜像进行抓包，想看下DHCP四个报文的交互情况。
结果发现出现大量组播报文（ipv4mcast）。我们询问组播报文源地址163.42是哪台终端，客户查表是楼下音频控制电脑，表述近期由于音频出现杂音断续改过ip，由dhcp改成了163.42的固定地址，我和同事心疑，杂音和地址有啥关系，再者DHCP改固定地址这个也无所谓啊，都是同一网段，检测也没有地址冲突。音频控制电脑具体拓扑如下：
恢复音频控制电脑的DHCP，重新抓包。依旧收到大量组播报文。
和之前没有区别，只是163.42变成了DHCP获取到的163.232。在这期间测试发现，两台终端只运行一台是正常的，同时运行，音频控制终端就会宕机。于是我怀疑是不是音频控制终端与音频控制电脑有物理连接，导致音频控制电脑大量流量从音频控制终端走，然后致使音频控制终端宕机。经排查没有物理连接。
随后分析wireshark抓包，在音频控制终端开机后并没有discover报文发出，而是几乎在一瞬间发来了七八百个组播报文。源地址和源mac均是音频控制电脑。可以看到报文长度也不小（Len=1161），反复测试，排除其他所有原因，断定音频控制电脑会向组播组中发送大量组播报文包括音频控制终端，直至音频控制终端设备性能耗尽，导致设备宕机。询问客户音频控制电脑是不是会向其他设备一直发送一些指令，客户追忆，好像是改过一个什么组播东西，之前是单播，为了省事用了组播。也是因为之前那90次音频出现故障后修改的。客户联系相关修改人员恢复，故障排除。
（PS：为啥不早告诉我们你们出现故障前后有什么操作，有啥其他相关的故障。真无语了，我到现场第一件事就是问最近有没有动过相关的东西，都是一个劲的说没有没有！合着搁这给我出排障呢，我排一点你说一点。网络小白工作一年多点，大佬轻喷！）
发布者：admin，转转请注明出处：http://www.yc00.com/web/1754982910a5223957.html
评论列表（0条）