我们有一个100Mbit的公司networking， 50台工作站（主要是XP-W8，主要是DHCP），几台服务器（其他），其他一些设备（VOIP适配器等）以及两台Zyxel ES-1552交换机。 有一个域（AD / Windows Server 2012）正在运行。
networking通信中有非常烦人的冻结，持续时间从几秒到一分多钟，涉及很多（但不是全部）工作站（不pipe是DHCP /静态IP）。 这些冻结通常发生在networkingstream量较强的早上。
例如，在同一个位置有三个XP工作站（A，B，C）。 发生冻结时，A和B完全停止联网（没有Internet / Intranet，由于映射的networking驱动器，Windows资源pipe理器不响应，A不能ping B或其他任何东西（超时）），并且可以持续一分多钟。 与此同时，工作站C不会遇到任何问题。 之后，通信恢复，三台工作站通信都没有任何问题。
我是一个程序员，而不是专业的networkingpipe理员。 我试图重置交换机，查看日志，我甚至安装了Microsoftnetworking监视器，但没有帮助。 在过去的三个月中，我们的networking基础设施发生了一些重大变化（新的服务器，新的工作站，域名），但是我无法将这些问题与特定事件联系起来。
什么是build议的步骤来诊断这个问题（没有把networkingclosures）？ 非常感谢。
可能有线索发生了什么事情。 这可能在您的域控制器或工作站上。
你想做的最后一件事情是做出意想不到的改变，你的整个networking都停止了。 还要检查这些事情是否在运行less的情况下发生，这可能是进一步调查的线索。
隔离networking上的问题，使用stream量监视工具来帮助find它发生的地方。
由于瓶颈较小，通常bufferbloat位于正在退出的路由器上，但configuration不当的交换机或路由器可能会出现这种情况。
有可能你的networking被arp中毒了，或者是configuration不当的设备，或者是（不太可能）的人。 设备可能会中毒您的networking，直到再次发送正确的更新。
更换更好的开关（如许多build议）可能会有所帮助。 但是这个问题在没有改变硬件的情况下就消失了。 三个不同的变化已经完成。 其中之一或他们的组合已经帮助。
当人们已经在工作的时候，仍然运行的默认Windows Server Backup已经被multithreading模式下的7-Zip所取代，这个模式在人们上class之前要快得多并且完成。 这是服务器发送平均值的最可能的原因。 300Mbit / s通过一个Switche的吉比特链接到NAS。 结合阅读/保存大文件的人，这可能是一个问题。
损坏的网线/ STP /（未使用，但连接到其中一个交换机）已被取消。 （这可能会导致一种短路。）
服务器上的Hyper-V虚拟交换机已closures。 即使数据没有通过它（我希望如此 – 使用两个物理Broadcom中的另一个），数据传输速率已经提高。 自7-Zip备份以来，甚至快了15％。
Wireshark发现，一个带有Attansicnetworking适配器（某种程度上已经损坏）的工作站负责所有networkingstream量（!!!）的95％。 用另一个networking适配器replace之后，还没有发现广播风暴。
这听起来像生成树收敛到我。 不知道这些交换机能做什么，但是基于标准的快速生成树实现需要大约45秒的时间才能将一个端口从新build到转发。 这可能是你的交换机不堪重负，不得不在STP端口的一个子集上做些什么？ 不熟悉合勤产品…
你有从pipe理GUI的任何日志？ 交换机是否设置为生成树，并且有快速STP或MST的选项吗？
正如其他人提到的，你有没有考虑将这些设备升级到更多的企业级？ 就像一个48端口的Cisco 2960一样，它将非常适合小型商务办公室，而且在eBay上它们是非常合理的。 根据你想要的function，Config的范围从简单到复杂。