情景：小型企业，拥有约40名用户，支持Watchguard XTM 3.0防火墙和20Mb专线互联网连接。
问题：用户偶尔会遇到networking连接中断。 在VOIP呼叫期间，这尤其令人讨厌，例如Skype连接中断。 当退出发生时，浏览到互联网网站也受到影响。 辍学是足够经常的业务问题，虽然大部分时间一切都很好。
评论：我们认为这个问题是在我们的最后，因为从其他地方，如家庭宽带呼叫相同的Skype收件人似乎工作正常。 从ADSL到租用线路的升级，也一直存在问题。 然而，我们想知道如果问题是在局域网或广域网上。 交换机目前是未被pipe理的，但很快就会被新的pipe理型交换机取代。 据我们所知，局域网内任何地方的用户都会出现丢包现象。
任何想法如何追查辍学的原因？ 我想知道是否有一种方法来testingXTM内的连接的连续性？ 你可以很容易地看到没有长时间的辍学，但我们如何testing短暂的辍学（但足以打破Skype电话）呢？
更可能的原因是局域网上的东西 – 我们如何缩小这一点，而不会让人们长时间断开连接？
蒂姆
寻找这类问题的根源可能是非常令人沮丧的，特别是如果它们很less的话。 但是，这是我如何处理间歇性networking问题
步骤1和2应该是相对简单的。 在具有完整path和相关系统的白板上绘图是有帮助的。 对于第3步，我倾向于使用Nagios或其他长期监视解决scheme。 nagios有很多插件可能是有用的，你可以configuration它来从你的NOC中以非常高的分辨率监视系统的许多属性。 监测有两个目的。 其中之一是收集信息以供后期debugging，但也会告诉您有关哪些问题可以让您更容易将它们与源相关联。 对于间歇性networking连接问题，我确保将路由监视和连接testingconfiguration到path上的所有系统。
一旦find问题的解决scheme，我将其部署，并将监控留在原地，直到我确信问题已经解决。
顺便说一句，非pipe理设备在生产networking中没有地位，你现在可能已经弄清楚了。 debugging局域网中的问题，至less在交换机上不能访问SNMP是一件非常头疼的事情。 如果你不幸在networking中某个地方的两个networking端口之间的单个补丁足以使你的networking崩溃并烧毁…
我想你可以对交换机进行简单的pingtesting，并logging/追踪丢失发生的位置和时间（以及发生的交换机），然后将这些数据与延迟相关联，并从pingtesting中删除ping。 这不会是特别准确，但是这是最好的，你会用非pipe理交换机。 对于是否对任何一台特定交换机进行限制，或者在局域网中的某个点出现networking饱和或带宽不足等问题，也应该进行合理的评估。
最终，解决scheme和真正缩小这个差距的唯一方法是获得pipe理型交换机，以便获得networking使用情况的详细地图（这可能是networking饱和问题，或带宽不足导致数据包被丢弃的地方沿线），并设置QoS。 如果您使用VOIP，则需要QoS 。
如果你有一些实际上打破了Skype通话，而实际连接短时间中断（小于15秒），这可能是积极拆除连接的东西。
对于诊断，您可以采取一种分析方法，在其中一个受影响的站点上运行完整数据包跟踪（使用Wireshark或networking监视器），直到问题发生，并查看跟踪Skype连接的UDP数据包交换原因的可能线索已被中断（因为Skype通话可能是在通话时唯一使用频繁使用的基于UDP协议，您应该能够轻松识别该通信stream）。 您可能会看到来自path中某个路由器的ICMP目标无法访问的数据包，这会向您提供进一步查看的提示，或者仅显示任何请求的响应数据包，表明它们之间存在连接问题客户端和networking的其他部分。
您还可能需要浏览Watchguard的日志，以查看是否有任何条目会与报告的连接拆解相关联。 客户端的日志也是一样的，看它是否可能丢失连接和/或重新configurationIP接口。
另外，考虑可能的故障点并尝试从这些点的后面logging连接数据，例如
ping到内部服务器以检查它是否与交换基础设施有关