ZDNet至顶网软件频道消息:某电力公司用户反映访问公司服务器非常慢,网络基本上处于瘫痪状态。用户通过网管软件对网络设备和服务器的性能进行监控,找出问题是交换机CPU利用率达99%,而服务器性能正常。对于交换机的CPU高负荷运转,通过各方面排查最终没有找到问题原因。这种故障问题持续已有2天,在部署科来回溯分析系统后,对内网核心交换机(全端口RX镜像)的流量进行了7×24小时监控,通过回溯分析系统提取出问题时段的通信数据,我们定位到导致网络瘫痪的主要原因。用户的网络环境示意如下:
由于本案例中核心交换出现异常,需要部署科来回溯分析系统对内网进行全面的监控和分析,因此采用的是核心交换全端口镜像的方式。
案例分析
由于时间原因无法到现场排查问题,对于核心交换机CPU利用率99%,开始我们认为是流量拥塞或者蠕虫疯狂扫描所导致。在故障时间里网管下载回溯设备中的数据包回传,数据流量478MB左右,峰值大约100Mbps,抓包时间不足2分钟。峰值流量(核心交换全端口)都在100Mbps一下,对于千兆网络来说这种规模的流量不足以造成交换机高使用率。如下图:
通过科来便携式软件将流量导入,在概要统计表的数据包分布中,发现网络中存在异常小包(小于255大于64),流量过多,每秒钟2万多个小包。在短时间内产生大量小包,有以下几种可能:ARP广播、DOS攻击、蠕虫扫描、UDP攻击等。因此在分析的时候一般要抓住以下几点,每秒数据包个数、发包数量、包的收发比。我们以IP端点为基准对每秒数据包个数进行排序,可以发现172.168.46.81地址在一秒钟内发出13882个数据包,在不到2分钟时间里发出294094个数据包,且包的发收比很大。为了进一步分析此地址异常行为,对它进行定位分析。
直接对异常此地址产生的UDP报文会话进行深入分析,如下图:
通过上图可以看出内网主机172.168.46.81向104.96.172.0和184.89.172.0(非法地址)及172.168.46.254疯狂发包,源端口为1102、目标端口6900。在不到2分钟时间里产生将近60万个UDP小包。在短时间里核心交换机对于收到目标是104.96.172.0、184.89.172.0需要进行三层转发,而收到目标是172.168.46.254且端口是6900(核心交换的地址)核心交换机会产生大量ICMP端口不可达信息。对此核心交换在短时间里处理主机172.168.46.81产生巨多数据报文,还要加上正常访问流量,最后不得不导致CPU利用率过高。
分析结论
1、用户正常通讯流量,不会对核心交换造成高使用率。
2、主机172.168.46.81感染恶意程序对交换机实施UDP泛洪攻击,是导致此次网络瘫痪的原因。
分析完后通过和网管沟通,将此主机网线断开,核心交换利用率很快正常,网络随之也平稳运行。对于此次网络故障超出我们的想象,一台普通主机在几十秒之内就可以将市级规模的网络攻击瘫痪。真可谓四两拨千斤!!!对于网络运维部门当前网络注重资源、设备的管理和监控,建议加强对网络中通讯流量的透视分析。
好文章,需要你的鼓励
科技亿万富翁拉里·埃里森资助的研究团队将向英国牛津大学投资1.18亿英镑,用于将AI技术应用于疫苗研究。牛津疫苗研究小组将领导这一项目,研究人体免疫系统对严重细菌感染和抗生素耐药性的反应。该项目由曾主导新冠疫苗试验的安德鲁·波拉德教授领导,计划采用人体挑战模型,让志愿者在受控条件下接触细菌,然后运用现代免疫学和AI工具来精确识别预测保护效果的免疫反应,以开发针对致命疾病的创新疫苗。
伦斯勒理工学院研究团队通过网络科学方法首次系统揭示了大语言模型的内部"认知架构"。研究发现AI模型采用类似鸟类大脑的弱定位架构,模块间通过分布式协作而非专业化分工来处理认知任务。这一发现颠覆了基于功能模块优化的传统思路,指出应充分利用网络级协作来提升AI性能。
据报道,ChatGPT开发商OpenAI计划在印度建设一座耗电量超过1吉瓦的数据中心,目前正寻找当地合作伙伴。该设施预计可容纳至少5.9万片英伟达B200芯片。这可能是OpenAI全球数据中心计划的一部分,旨在为国际用户提供更低延迟服务。OpenAI CEO奥特曼将于下月访问印度,公司还计划年底前在新德里开设办事处。
腾讯和清华研究团队首次从数学理论角度解释了为什么AI需要外部工具。研究证明纯文本AI存在"隐形枷锁",无法突破预训练的能力边界,而工具集成能打破这种限制,让AI获得全新的问题解决策略。团队还开发了ASPO算法,解决了训练AI更早使用工具的技术难题。实验显示配备工具的AI在数学问题上全面超越纯文本版本,展现出三种新奇认知模式,为构建更强大的AI系统提供理论指导。