最近被朋友拉去处理一个挺典型的网络故障公司里“随机终端断网”断一下又自己恢复客户自己查了好几天没头绪。我过去看了不到半天就定位到了根因说穿了其实特别简单——不是硬件坏了也不是被攻击就是一个常用配置没配好把整个地址池体系给搞出了冲突。这类案例在中小企业里太常见了处理过一次以后你会对很多“默认配置”多一层警惕。这篇就把完整的排查过程、定位思路、修复手法和预防方案写出来给同样被“随机断网”折磨的运维一个参考。1. 先还原现场随机断网到底怎么个“随机”法1.1 故障表象与业务影响先交代一下现场环境。这家公司办公区大概三百来个有线终端加上几十台无线设备网络架构不算复杂核心交换机一台下面挂了若干台接入交换机网关做在核心上DHCP由一台Windows服务器承担无线网络走的是企业级AP加无线控制器。故障现象用一句话概括就是没有固定规律地今天这个工位的电脑上不了网明天那个工位打印机掉线后天又变成会议室投屏设备断连。断网时间短则几十秒长则两三分钟然后自己恢复。掉线期间终端ping网关会丢包访问内网服务器和互联网都不通但交换机端口状态、网线连接指示灯都正常。最让人头疼的是这个“随机性”。如果只是某一个工位、某一台电脑固定断网那大概率是网线、端口、电脑网卡的问题逐个更换就行了。但现在是“打地鼠”式分布没有固定时间、没有固定设备、没有固定区域网络团队第一反应是怀疑有环路或者广播风暴但检查了一圈也没发现明显异常。更麻烦的是故障会间歇性影响业务。办公时段开会开到一半投屏断了财务导出报表时断网导致文件没保存成功研发同事SSH到服务器敲命令敲到一半连接被重置。这些影响单独看都不致命但组合在一起就非常影响办公效率也会让管理层对网络团队的专业能力产生质疑。1.2 第一轮排查物理层与二层的常规检查遇到这种问题我一般不会一上来就抓包而是先把“地基”扫一遍排除掉低层问题避免后面拿着错误方向去猜。第一项检查的是物理链路。登录核心交换机和接入交换机查看所有相关端口的错误计数包括CRC错误、碰撞、超时错误等。同时用测线仪抽测了几个出问题比较频繁的工位网线又查看了光模块的光功率和温度数据。结果都正常说明物理层被排除了。第二项检查的是二层环路和广播风暴。生成树协议的状态、端口角色、阻塞端口逐个确认没有异常。再看交换机CPU负载和流量统计也没发现广播包异常飙高。如果真有环路广播流量会把交换机CPU打满这个现象在核心交换机上会非常明显当时完全没看到。第三项检查的是网关和DHCP服务器状态。核心交换机CPU利用率整体不高内存正常。Windows DHCP服务器上事件日志里没有明显的报错地址池总量和租约数量在合理范围内看起来也没被耗尽。到这里常规三板斧用完了问题还没浮出水面。网线、端口、二层环路、设备负载这些最常见的嫌疑对象都被排除。我判断这个问题的层级大概率在三层以上而且很可能是“间歇性地址冲突”或“ARP层面的异常交互”。这时候就要上抓包了只有把真实的数据包拿到手里才能把“随机”变成“可解释”。
最近被朋友拉去处理一个挺典型的网络故障公司里“随机终端断网”断一下又自己恢复客户自己查了好几天没头绪。我过去看了不到半天就定位到了根因说穿了其实特别简单——不是硬件坏了也不是被攻击就是一个常用配置没配好把整个地址池体系给搞出了冲突。这类案例在中小企业里太常见了处理过一次以后你会对很多“默认配置”多一层警惕。这篇就把完整的排查过程、定位思路、修复手法和预防方案写出来给同样被“随机断网”折磨的运维一个参考。1. 先还原现场随机断网到底怎么个“随机”法1.1 故障表象与业务影响先交代一下现场环境。这家公司办公区大概三百来个有线终端加上几十台无线设备网络架构不算复杂核心交换机一台下面挂了若干台接入交换机网关做在核心上DHCP由一台Windows服务器承担无线网络走的是企业级AP加无线控制器。故障现象用一句话概括就是没有固定规律地今天这个工位的电脑上不了网明天那个工位打印机掉线后天又变成会议室投屏设备断连。断网时间短则几十秒长则两三分钟然后自己恢复。掉线期间终端ping网关会丢包访问内网服务器和互联网都不通但交换机端口状态、网线连接指示灯都正常。最让人头疼的是这个“随机性”。如果只是某一个工位、某一台电脑固定断网那大概率是网线、端口、电脑网卡的问题逐个更换就行了。但现在是“打地鼠”式分布没有固定时间、没有固定设备、没有固定区域网络团队第一反应是怀疑有环路或者广播风暴但检查了一圈也没发现明显异常。更麻烦的是故障会间歇性影响业务。办公时段开会开到一半投屏断了财务导出报表时断网导致文件没保存成功研发同事SSH到服务器敲命令敲到一半连接被重置。这些影响单独看都不致命但组合在一起就非常影响办公效率也会让管理层对网络团队的专业能力产生质疑。1.2 第一轮排查物理层与二层的常规检查遇到这种问题我一般不会一上来就抓包而是先把“地基”扫一遍排除掉低层问题避免后面拿着错误方向去猜。第一项检查的是物理链路。登录核心交换机和接入交换机查看所有相关端口的错误计数包括CRC错误、碰撞、超时错误等。同时用测线仪抽测了几个出问题比较频繁的工位网线又查看了光模块的光功率和温度数据。结果都正常说明物理层被排除了。第二项检查的是二层环路和广播风暴。生成树协议的状态、端口角色、阻塞端口逐个确认没有异常。再看交换机CPU负载和流量统计也没发现广播包异常飙高。如果真有环路广播流量会把交换机CPU打满这个现象在核心交换机上会非常明显当时完全没看到。第三项检查的是网关和DHCP服务器状态。核心交换机CPU利用率整体不高内存正常。Windows DHCP服务器上事件日志里没有明显的报错地址池总量和租约数量在合理范围内看起来也没被耗尽。到这里常规三板斧用完了问题还没浮出水面。网线、端口、二层环路、设备负载这些最常见的嫌疑对象都被排除。我判断这个问题的层级大概率在三层以上而且很可能是“间歇性地址冲突”或“ARP层面的异常交互”。这时候就要上抓包了只有把真实的数据包拿到手里才能把“随机”变成“可解释”。
