TCP/IP网络故障诊断的结构化方法(一)

    “…服务器…”

　　你搞定了这个用户，而且搞定了那台服务器，也搞定了其间的网络。它们仍不能连接?为什么呢?需要注意的是那台服务器到底在什么地方呢?它在用户的子网上吗?在一个相邻的子网上吗?在一个不同的部门上吗?在一个不同的楼层上吗?在一个不同的大楼上吗?是哪种网络将用户与特定的服务器连接起来?是无线以太网吗?是无线局域网吗?是互联网上的VPN通道吗?是拨号的modem连接吗?是线缆modem还是DSL modem?首先决定用户和服务器之间的连接类型(有可能是几种)，然后思考哪个地方有可能出现故障?有可能是CSU/DSU出了故障，可以试着给它重新加电或与应该监视CSU/DSU的供应商联系。也有可能是某人在打扫卫生时碰到了电源开关，导致某个以太网交换机离线。如果你用的是可网管型交换机，也可以检查网络管理软件的警告信息。也有可能是远程服务器所在的办公室发生了电源中断。可以试着电话咨询一下。

　　用户是仅与一台服务器无法连接，还是无法与多台服务器不能连接?其他人也不能连接到那些服务器上吗?在受影响的服务器之间有什么共同的东西吗?(问题有可能与用户的计算机有关，更有可能与网络架构自身有关)

　　“…现在”

　　时间因素在故障诊断中是至关重要的。应该问一下：问题是刚刚发生吗?上次成功连接到服务器是在什么时候?这种现象持续了多长时间?是连续性的还是间断的?断断续续的网络问题涉及到不可靠的WAN链接以及其它一些难于解决的问题，特别是这些问题持续很短暂时间或偶尔出现时更是这样。

　　时间因素还有可能将问题与可能影响网络的其它情况联系起来。问题是出现在今天上午10点20分吗?彼时你的网络还出现了哪些问题?WSUS服务器上打补丁了吗?域服务器上的预定维护实现了吗?

　　结构化的方法

　　笔者自己的TCP/IP网络的结构化故障诊断的方法由三个关键部分组成：

　　1. 决定问题的因素。也就是说要考虑如下方面：

　　客户端：即出现问题的客户端
　　
    服务器端：客户无法访问的服务器、打印机或其它的网络资源(如互联网)等。
　　
    其间的网络：线缆(如果不是无线的话)、集线器、交换机、路由器、防火墙、代理服务器，以及客户端和服务器之间的其它网络架构。
　　
    环境：可能会影响你的网络的外部情况，如电源的波动、建筑物的维护等等。
　　
    范围：一个或多个有关的客户端/服务器端。
　　
    期间：连续的、间断的，还是偶尔的，何时开始等。
　　
    出现问题的连接类型：物理层、网络层、传输层还是应用层?身份验证还是访问控制?等等。
　　
    标志性信息：客户端机器上的出错消息，登录对话框等等。
　　
    2. 在考虑到以上问题因素时，决定需要应用哪些故障诊断措施，这些措施包括：

　　验证有关客户端、服务器和网络架构硬件的物理媒体。也就是说检查电缆，确保网络适配器正确安装，并进一步查找、验证可以显示媒体断开状态的网络连接。

　　验证有关客户端、服务器、网络架构硬件的TCP/IP配置。在客户端上这意味着检查IP地址、子网掩码、默认网关、DNS设置等等。对于网络架构硬件而言，也就是指路由器上的路由表和Internet网关。

　　验证有关客户端和服务器端的路由选择的连通性。也就是说要使用ping，pathping，tracert，或其它类似的工具，便于在网络层上验证端到端的TCP/IP的连接性;采用数据包嗅探以监视传输层会话;使用nslookup，telnet和其它的工具来诊断包括域名解析问题、身份验证等应用层问题。

　　3.理解之、询问之、测试之:

　　理解协议如何工作，数据包如何由路由表转发，netdiag.exe等工具能够告诉你什么是非常关键的。成功的TCP/IP故障诊断是建立在理解TCP/IP如何工作和有关测试工具的基础之上的。如果你从来没有努力理解网络监视器的跟踪模式，那么你在诊断某些问题时就会遇到困难。

　　问一些恰当的问题对于成功的故障诊断也很关键。要学会何时按部就班，何时以跳跃性思维直奔主题是故障诊断艺术的本质所在，这还括充分使用你的左右脑，即要有充分的想象和缜密的思维。

　　最后，踏踏实实地测试，并隔离问题是很关键的，为此你需要故障诊断的工具箱。而且没有什么比丰富的经验更能帮助你解决复杂问题了。

　　小结

　　诊断TCP/IP网络的故障时可能会使人灰心丧气，不过也充满乐趣。在未来的文章中，我们将祥细阐述故障诊断的措施和工具，以帮助你成功地解决网络中出现的问题。
 

上一页  [1] [2] 

【责编:Zenghui】