如何在小型networking中诊断严重的networking问题?

我们有一个非常小的networking,pipe理和非pipe理交换机(Netgear GS748T,Linksys SLM2024,DGS-1008D,DES-1008D,DES-1026G,SRW224G4),约8-10个主机Hyper-V,多个虚拟机,大约100个本地用户和另外100个VPN用户(一直没有连接)。 最近,我们在networking中引入了Forefront TMG(使其成为一个中心点),并对VLAN进行了大的改变(从一个192.168.1.Xnetworking到5-10个VLAN的分离networking,到testing机器,关键服务器,iSCSI,Heart Bit – 集群HV,可信用户,不可信用户等)。 大部分(如果不是所有)网卡都使用Teaming,Aggregation和Trunk。

在过去的几个星期里,在备份完成的夜晚,由于iSCSI问题,networking一直不稳定。 昨天我们的networking决定在白天下去,并且不能用2个小时。 在此期间,交换机被吊挂两次,需要进行硬复位,整个networking在此期间无法正常工作。 2个小时后,一切都恢复正常,但似乎很快就会回来。

交换机不提供很多monitoring capabilities ,备份iscsi驱动器也不提供。 TMG中的一些错误:

Forefront TMG从172.16.10.5断开非TCP连接,因为超出了此IP地址的连接限制。 应该为链接的代理服务器的IP地址和背靠背的具有NAT关系的Forefront TMG计算机configuration较大的自定义连接限制。

Forefront TMG从172.16.10.12断开非TCP连接,因为超出了此IP地址的连接限制。 应该为链接的代理服务器的IP地址和背靠背的具有NAT关系的Forefront TMG计算机configuration较大的自定义连接限制。

来自源IP地址178.215.xxx.xxx的并发TCP连接数超出了configuration的限制。 因此,Forefront TMG将不允许从此源IP创build新的TCP连接。 该IP地址可能属于攻击者或受感染的主机。 有关Forefront TMG洪水减灾的更多信息,请参阅产品文档。

来自源IP地址77.1xxx.xxx的拒绝连接数超过了configuration的限制。 这可能表示主机正在感染或正在尝试对Forefront TMG计算机进行攻击。

Forefront TMG从172.16.10.10断开非TCP连接,因为超出了此IP地址的连接限制。 应该为链接的代理服务器的IP地址和背靠背的具有NAT关系的Forefront TMG计算机configuration较大的自定义连接限制。

Forefront TMG从172.16.10.16断开非TCP连接,因为超出了此IP地址的连接限制。 应该为链接的代理服务器的IP地址和背靠背的具有NAT关系的Forefront TMG计算机configuration较大的自定义连接限制。

来自源IP地址195.ZZZ的拒绝连接数超过了configuration的限制。 这可能表示主机正在感染或正在尝试对Forefront TMG计算机进行攻击。

来自源IP地址85.ZZZ的拒绝连接数超过configuration的限制。 这可能表示主机正在感染或正在尝试对Forefront TMG计算机进行攻击。

Forefront TMG从172.16.231.12断开非TCP连接,因为超出了此IP地址的连接限制。 应该为链接的代理服务器的IP地址和背靠背的具有NAT关系的Forefront TMG计算机configuration较大的自定义连接限制。

Forefront TMG无法从stooq.pl解压缩响应正文,因为响应是由Forefront TMG不支持的方法压缩的。 如果将Web服务器configuration为通过Forefront TMG不支持的方法压缩响应,则无论请求的压缩types如何,都会发生这种情况。

如果您希望Forefront TMG阻止此类响应,请configuration策略规则的HTTP策略以在响应中阻止Content-Encoding标头。 否则,这样的响应将在不解压缩的情况下被转发给客户端并且可以被caching。 您可以取消或减lessForefront TMG Management中由此事件生成的警报的频率。

连接validation程序“Farm:Sharepoint.xxx.pl – Farm”在尝试连接到14cms.xxx.xx时报告了错误。 原因:请求已超时。

连接validation程序“DHCP1”在尝试连接到DHCP1.xxx.xx时报告了错误。 原因:请求已超时。

我们已经使用了TMG,并且为AD / DNS服务器设置了一些更高的限制,因为我们之前发送了这个消息,但似乎发生了一切。

“在这段时间内,交换机挂了两次,需要硬复位”

我不想成为这里的精英,但Linksys / D-Link / Netgear甚至不是中等规模的硬件。 iSCSI和虚拟化需要一个非常稳定和快速的networking来正确执行。

我强烈build议你买更好的networking设备(思科,惠普等)。

查看TMG中与内部stream量有关的错误消息(172.16.xx是一个很好的起点)。 找出与这些主机相关的主机,以及这些是否是防火墙针对这些主机上的通信采取的适当操作。

永远不要认为防火墙带有适当的configuration, 特别是如果要在内部部署防火墙的话。

我还build议为您的iSCSI存储networking使用单独的交换机,而不是尝试使用VLAN隔离stream量。 如果你正在使用虚拟机硬盘驱动器,你真的需要正确地获得iSCSIstream量!