我们有一个大约40个工作站（主要是Windows）和一对服务器的局域网。 他们都使用内部DNS（运行BIND 9.5.0-P2 196.168.0.4 ）和一个作为路由器的本地PC的网关（运行OpenBSD Packet Filter的192.168.0.1 ）。
在过去的几个月中，在工作日的某些时间点，networking速度放缓，无法做任何与互联网有关的事情。 在8.8.8.8不好的时候，
12:16:12.078: Timeout waiting for seq=11a1 12:16:13.484: From 8.8.8.8: bytes=60 SEQ=11a9 TTL=48 ID=0000 time=399.334ms 12:16:15.078: Timeout waiting for seq=11a4 12:16:15.437: From 8.8.8.8: bytes=60 SEQ=11ab TTL=48 ID=0000 time=355.409ms 12:16:18.078: Timeout waiting for seq=11a8 12:16:19.453: From 8.8.8.8: bytes=60 SEQ=11af TTL=48 ID=0000 time=376.317ms 12:16:21.078: Timeout waiting for seq=11aa 12:16:21.078: Timeout waiting for seq=11ac 12:16:21.390: From 8.8.8.8: bytes=60 SEQ=11b1 TTL=48 ID=0000 time=306.727ms 12:16:22.437: From 8.8.8.8: bytes=60 seq=11b2 TTL=48 ID=0000 time=364.351ms 12:16:23.453: From 8.8.8.8: bytes=60 seq=11b3 TTL=48 ID=0000 time=371.944ms 12:16:24.078: Timeout waiting for seq=11ad 12:16:24.078: Timeout waiting for seq=11ae 12:16:26.390: From 8.8.8.8: bytes=60 SEQ=11b6 TTL=48 ID=0000 time=307.729ms 12:16:27.078: Timeout waiting for seq=11b0 12:16:29.437: From 8.8.8.8: bytes=60 SEQ=11b9 TTL=48 ID=0000 time=361.575ms 12:16:30.078: Timeout waiting for seq=11b4 12:16:30.453: From 8.8.8.8: bytes=60 seq=11ba TTL=48 ID=0000 time=367.647ms 12:16:33.078: Timeout waiting for seq=11b5 12:16:33.078: Timeout waiting for seq=11b7
在这个确切的情况下，如果我把DNS（在.0.4 ）关掉，几秒钟之后，networking的健康状况就会变得非常好：
12:47:43.046: From 8.8.8.8: bytes=60 seq=190b TTL=48 ID=0000 time=70.555ms 12:47:44.046: From 8.8.8.8: bytes=60 seq=190c TTL=48 ID=0000 time=82.684ms 12:47:45.046: From 8.8.8.8: bytes=60 seq=190d TTL=48 ID=0000 time=72.368ms 12:47:46.062: From 8.8.8.8: bytes=60 seq=190e TTL=48 ID=0000 time=84.310ms 12:47:47.046: From 8.8.8.8: bytes=60 seq=190f TTL=48 ID=0000 time=75.137ms 12:47:48.046: From 8.8.8.8: bytes=60 seq=1910 TTL=48 ID=0000 time=75.791ms 12:47:49.062: From 8.8.8.8: bytes=60 seq=1911 TTL=48 ID=0000 time=94.252ms 12:47:50.046: From 8.8.8.8: bytes=60 seq=1912 TTL=48 ID=0000 time=76.547ms 12:47:51.046: From 8.8.8.8: bytes=60 seq=1913 TTL=48 ID=0000 time=70.251ms 12:47:52.046: From 8.8.8.8: bytes=60 seq=1914 TTL=48 ID=0000 time=83.033ms 12:47:53.046: From 8.8.8.8: bytes=60 seq=1915 TTL=48 ID=0000 time=76.589ms 12:47:54.046: From 8.8.8.8: bytes=60 seq=1916 TTL=48 ID=0000 time=82.060ms
这是非常一致和可重复的。 事实上，我平8.8.8.8 （谷歌的公共DNS）是完全随机的，只是一个方法，我必须testing互联网连接。 我可以ping 206.190.36.45 （雅虎公共网站的IP）。
DNS不对外开放。 所以我认为，也许一个（或更多）工作站会非常不好地使用DNS（可能间接通过病毒）并用请求或其他东西来洪水。 问题是我无法追溯到这一点。 在0.4机器top给我没有CPU的可疑活动和0.1 （网关）过滤使用dst host 192.168.0.4 pftop不给我任何内部IP使用DNS。
我已经尝试拔出以太网电缆的工作站逐一find一个可能的违规工作站，但这个过程是不是很快，准确，当networking稳定，我不确定是否是由于上一个工作站我堵塞了，还是networking再次变好了。
任何关于下一步看什么的想法？
根据提供的信息，我个人会倾向于L2交换回路和/或DNS服务器上错误configuration的链路聚合。 它也可能是L3路由回路，但似乎不太可能。 但是，如果没有更多的信息，我无法确定。
22的捕获是我没有评论这个问题的声望，以澄清问题，并确定这个答案是否有任何价值之前，我发布。 希望这会指出你在正确的方向，你很快就会find你的答案。
我不确定证据是否指向DNS。 它看起来像你的互联网连接正在淹没，基于长平时间和数据包丢失。 我build议禁用DNS服务器是防止使用Internet连接的一个或多个客户端（可能会因为病毒而导致行为exception），因为它不能再查找主机名。 这减less了stream量，Internet连接开始正常运行。
我会build议监测互联网连接的东西，可以报告顶级谈话，以帮助您find违规的机器。
如果您的DNS服务器是可公开访问的，那么您可能是DNS放大攻击中的一名棋子，所产生的传出stream量压倒了您的可用带宽。