我现在想知道，有哪位遇到过类似问题，形成此问题的原因是什么？有什么好的解决办法吗？谢谢！！！
9 个解决方案
#1
数据包在网络上的不停的传播都称之为网络广播风暴，最简单的实例就是将网线连接在交换机上的任意两口，就会发生风暴，交换机的所有端口状态灯就会常闪。所以在交换机上就有了STP树来避免回路，也就是电源一通，所有灯都会亮一下然后灭掉。广播风暴在广域网上是一场灾难，所以在数据包传送过程中加入了TTL存活时间，并在路由协议加入了十六跳的限制过滤数据包，早期的IPX/SPX由于能穿越路由造成风暴，所以针对他开发了欺骗协议以限制他的广播，并慢慢淘汰了NOVELL网，所以消除广播基本上就是避免回路、划分子网、限制路由等方法。
可以使用协议分析器或网络监视器来找出是网络中哪台计算机导致了风暴。协议分析器可以找出工作站的IP地址或者MAC地址，但是跟踪MAC地址比较困难，甚至不可能。(如果可能的话，记录网络中每一台机器的硬件地址，有助于迅速解决网络广播风暴问题)。
当怀疑网络可能发生广播风暴时，可用网络监视器捕获数据来分析，当然一定要能根据捕获的数据来判断网络中传输的是正常数据还是发生了广播风暴。
可以使用协议分析器或网络监视器来找出是网络中哪台计算机导致了风暴。协议分析器可以找出工作站的IP地址或者MAC地址，但是跟踪MAC地址比较困难，甚至不可能。(如果可能的话，记录网络中每一台机器的硬件地址，有助于迅速解决网络广播风暴问题)。
当怀疑网络可能发生广播风暴时，可用网络监视器捕获数据来分析，当然一定要能根据捕获的数据来判断网络中传输的是正常数据还是发生了广播风暴。
#2
按你所说，都已经经过排查了，既然找到了交换机就换掉个，呵呵
但是我觉得交换机的可能性比较少吧，是你的计算机出问题吧
抓包看看，到底是哪个计算机在不停的发包呀，只要找出个计算机就行了呀
估计是SQL Server的补丁没有打上，找到那台计算机，看看进程里的的sqlserver这个进程是不是占用CPU，停止掉是不是就不会发包了，不会阻塞了，打个补丁就好了
如果不是，那就是蠕虫，或冲击波杀手了
但是我觉得交换机的可能性比较少吧，是你的计算机出问题吧
抓包看看，到底是哪个计算机在不停的发包呀，只要找出个计算机就行了呀
估计是SQL Server的补丁没有打上，找到那台计算机，看看进程里的的sqlserver这个进程是不是占用CPU，停止掉是不是就不会发包了，不会阻塞了，打个补丁就好了
如果不是，那就是蠕虫，或冲击波杀手了
#3
布线不规范造成的干扰也有可能
#4
不同意布线，布线不规范的话网管早通知他了，问问网管路由上有没收到发包信息
流量大也分是流入还是流出大...
流量大也分是流入还是流出大...
#5
还是用软件进行流量分析比较实际。你们用了SysGate之类的代理软件了吗？他好像就有这功能。如果有钱，用用硬件的QOS产品，更有效。
#6
你可以登录到交换机上看看到底是哪个端口流量大
或者
用最有效但是最没有效率的方法：拔线
一根线一根线的拔
或者
用最有效但是最没有效率的方法：拔线
一根线一根线的拔
#7
谢谢大家.
昨天又发生了一次.好像就是交换机或者某个HUB坏了.因为在夜里电脑不开机的时候一样有流量.可以排除是电脑的问题了.流量全都是向外发的包.
前几天我用network monitor抓了几个包,发现有一个MAC总向外发广播.但不多.流量大的时候一忙忘记抓了.那时候抓几个就好了!
交换机和HUB是不是应该也有MAC地址呢?每个端口一个?我如何才能知道端口的MAC呢?
交换机是不可网管的.登陆不了55555
昨天又发生了一次.好像就是交换机或者某个HUB坏了.因为在夜里电脑不开机的时候一样有流量.可以排除是电脑的问题了.流量全都是向外发的包.
前几天我用network monitor抓了几个包,发现有一个MAC总向外发广播.但不多.流量大的时候一忙忘记抓了.那时候抓几个就好了!
交换机和HUB是不是应该也有MAC地址呢?每个端口一个?我如何才能知道端口的MAC呢?
交换机是不可网管的.登陆不了55555
#8
没人知道吗?
#9
顶顶!~
#1
数据包在网络上的不停的传播都称之为网络广播风暴，最简单的实例就是将网线连接在交换机上的任意两口，就会发生风暴，交换机的所有端口状态灯就会常闪。所以在交换机上就有了STP树来避免回路，也就是电源一通，所有灯都会亮一下然后灭掉。广播风暴在广域网上是一场灾难，所以在数据包传送过程中加入了TTL存活时间，并在路由协议加入了十六跳的限制过滤数据包，早期的IPX/SPX由于能穿越路由造成风暴，所以针对他开发了欺骗协议以限制他的广播，并慢慢淘汰了NOVELL网，所以消除广播基本上就是避免回路、划分子网、限制路由等方法。
可以使用协议分析器或网络监视器来找出是网络中哪台计算机导致了风暴。协议分析器可以找出工作站的IP地址或者MAC地址，但是跟踪MAC地址比较困难，甚至不可能。(如果可能的话，记录网络中每一台机器的硬件地址，有助于迅速解决网络广播风暴问题)。
当怀疑网络可能发生广播风暴时，可用网络监视器捕获数据来分析，当然一定要能根据捕获的数据来判断网络中传输的是正常数据还是发生了广播风暴。
可以使用协议分析器或网络监视器来找出是网络中哪台计算机导致了风暴。协议分析器可以找出工作站的IP地址或者MAC地址，但是跟踪MAC地址比较困难，甚至不可能。(如果可能的话，记录网络中每一台机器的硬件地址，有助于迅速解决网络广播风暴问题)。
当怀疑网络可能发生广播风暴时，可用网络监视器捕获数据来分析，当然一定要能根据捕获的数据来判断网络中传输的是正常数据还是发生了广播风暴。
#2
按你所说，都已经经过排查了，既然找到了交换机就换掉个，呵呵
但是我觉得交换机的可能性比较少吧，是你的计算机出问题吧
抓包看看，到底是哪个计算机在不停的发包呀，只要找出个计算机就行了呀
估计是SQL Server的补丁没有打上，找到那台计算机，看看进程里的的sqlserver这个进程是不是占用CPU，停止掉是不是就不会发包了，不会阻塞了，打个补丁就好了
如果不是，那就是蠕虫，或冲击波杀手了
但是我觉得交换机的可能性比较少吧，是你的计算机出问题吧
抓包看看，到底是哪个计算机在不停的发包呀，只要找出个计算机就行了呀
估计是SQL Server的补丁没有打上，找到那台计算机，看看进程里的的sqlserver这个进程是不是占用CPU，停止掉是不是就不会发包了，不会阻塞了，打个补丁就好了
如果不是，那就是蠕虫，或冲击波杀手了
#3
布线不规范造成的干扰也有可能
#4
不同意布线，布线不规范的话网管早通知他了，问问网管路由上有没收到发包信息
流量大也分是流入还是流出大...
流量大也分是流入还是流出大...
#5
还是用软件进行流量分析比较实际。你们用了SysGate之类的代理软件了吗？他好像就有这功能。如果有钱，用用硬件的QOS产品，更有效。
#6
你可以登录到交换机上看看到底是哪个端口流量大
或者
用最有效但是最没有效率的方法：拔线
一根线一根线的拔
或者
用最有效但是最没有效率的方法：拔线
一根线一根线的拔
#7
谢谢大家.
昨天又发生了一次.好像就是交换机或者某个HUB坏了.因为在夜里电脑不开机的时候一样有流量.可以排除是电脑的问题了.流量全都是向外发的包.
前几天我用network monitor抓了几个包,发现有一个MAC总向外发广播.但不多.流量大的时候一忙忘记抓了.那时候抓几个就好了!
交换机和HUB是不是应该也有MAC地址呢?每个端口一个?我如何才能知道端口的MAC呢?
交换机是不可网管的.登陆不了55555
昨天又发生了一次.好像就是交换机或者某个HUB坏了.因为在夜里电脑不开机的时候一样有流量.可以排除是电脑的问题了.流量全都是向外发的包.
前几天我用network monitor抓了几个包,发现有一个MAC总向外发广播.但不多.流量大的时候一忙忘记抓了.那时候抓几个就好了!
交换机和HUB是不是应该也有MAC地址呢?每个端口一个?我如何才能知道端口的MAC呢?
交换机是不可网管的.登陆不了55555
#8
没人知道吗?
#9
顶顶!~