网络管理员如何评估网络故障

能不能期望我们每一位网管员都能够解决网络运行中出现的所有问题呢？通过多年网络管理的总结认为，如果预先采取一定的措施，并且使用正确的故障诊断方法，那么回答是肯定的。下面给出了一个较为完整的过程，希望对大家有所帮助。

及时更新网络图

首先应该绘制一个网络方框图。这个文档的作用是为从事故障诊断的人员提供一个关于网络布局和配置的全部信息的单一来源。网络图上包含的主要内容有：

*路由器的连接图；

*设备的序号、型号及端口情况；

*使用的路由协议（如RIP、OSPF等）；

*IOS版本（用于具有何种性能查找和判别）；

*已安装的模块；

*访问控制列表；

*地址（网络地址和序号，MAC地址更好）；

*交换机（型号）；

*集线器（Hub型号）；

*所有配置的拷贝。

当网络使用发生变化时，要及时更新网络图。如果没有更新网络图，那么您的网络图的用处就要大打折扣，这将是非常危险的。如果出现这种情况，您必须马上绘制一幅新的网络图，而不是依赖那个不能反映实际情况的老的网络图。

当网络以通常方式运行时，必须符合网络性能的基线。基线用来记录网络在低、中和高使用量时的信息量。它建立了一个网络运行性能的记录，该记录可以用来进行比较，以确定是否出现问题。网络运行性能基线中包含以下主要内容：

*网络上运行了哪些协议；

*每个协议使用的带宽百分比；

*每个协议的峰值使用量和平均使用量；

*数据包的大小以及每种大小数据包的百分比；

*循环冗余校验（Cyclical Redundancy Check，CRC）发现的错误的峰值和平均值；

*网段每秒钟传输的信息帧的峰值和平均值；

*是否存在超长的数据包；

*冲突域每秒产生的冲突的峰值和平均值；

*网段运行的峰值和平均值。

故障诊断方法与步骤

正确地确定问题是解决问题的关键。下面我们按照顺序介绍故障诊断方法、步骤。应该注意的是这些步骤往往是相互重叠的，而且解决问题的方法实质上是循环式的。

⑴确定网络问题的性质；

⑵收集有关的情况并对问题进行分析；

⑶分析问题产生的原因；

⑷设计一个解决问题计划；

⑸实现这个解决问题计划；

⑹评估该解决问题计划产生的结果；

⑺重复上面的操作，直到问题得到解决；

⑻将解决方案记入文档资料。

确定网络问题的性质实际上就是要提出问题。即“谁出了问题，是什么问题，何时产生和出现在何处”这样的形式。这些问题可能会多次出现，您可以向用户、网管员、以及遇到或者了解问题的其他人详细提问：谁受到了问题的影响？是单个用户还是存在共性的一组用户，甚至是整个网络中的所有用户呢？

若是单个用户可能出现下列若干问题中之一：

*物理层问题，包括发生故障的网络电缆。可用Ping来测试；

*在特定主机上的硬件故障。用Ping 127.0.0.1或Ping本机地址来检测；

*软件加载不正确或者崩溃了，尤其是网络协议出了问题。可重装软件或删除网络协议后重新加载网络协议；

*主机地址或者子网掩码设置不正确。可修正主机地址和子网掩码；

*默认网关配置不正确。可用Tracert检测，重新修正默认网关。

拥有公共属性或者遇到问题的一组用户可能出现下列若干问题：

*网络设备（比如集线器或者交换机）发生了故障；

*路由器接口发生故障；

*服务器发生故障；

*访问列表设置错误；

*VLAN配置错误。

在我们知道“谁出了问题”后，就要集中精力解决：这个问题有何表现？是没有连接还是只有部分连接的问题，或者是根本没有连接的问题呢？如果是没有连接的问题，那它就属于：

*硬件故障；

*远程通信服务故障；

*路由协议故障。

如果是部分连接的问题，那它属于；

*访问列表问题；

*子网掩码不正确；

*路由协议不兼容。

这个问题何时发生呢？是间歇性出现还是经常发生的问题，或者是刚刚发生的问题呢？

如是间歇性发生的问题，其原因可能是：

*远程通信服务故障；

*信息拥挤；

*路由循环。

如是经常发生的问题，那么原因是信息拥挤。出现新问题的原因是：

*访问列表发生变化；

*新的硬件故障；

*路由协议发生变化；

*新增加的路由。

正确确定网络问题的性质，是我们判断是广域线路问题还是局域网中的问题的基础。

解决故障步骤

收集有关的情况并对问题进行分析

主要包括对设备进行观察，设法了解问题究竟存在什么位置。可以通过查看路由器的接口和进程命令，查看内存、缓存和CPU的使用情况等等。在查看过程中，应记录发现的情况，以便评估存在问题的原因。如遇到间歇性失去连接的问题，注意查看该接口复位了多少次。如果问题与访问列表相关，就需要查看访问列表是如何设置的，与现有文档的注释进行比较，判断是否一致。如现有的设置与文档不一致，应审查更新文档的策略。在尽可能收集到各种情况后，即可转入对问题原因的分析工作。

分析产生问题的原因

就是要确定这个问题本身有什么表现，谁受到了这个问题的影响。如果我们不知道这个情况，就需要倒退一个或两个步骤，重新思考这个问题。如果收集到正确的信息，那么在解决问题模型中，这是最容易执行的步骤之一。知道谁受到了问题的影响，这个问题有何表现，问题在何时发生，以及问题发生在何处。剩下的唯一问题就是这个问题为何会发生。当我们对OSI模型有一个透彻的了解时，解决这个问题对故障诊断者来说就变得易如反掌了。因此要求我们对OSI模型的每一层协议功能要非常熟悉，才能从中获得重要的线索，以确定问题为何会发生。

当您认为问题的原因已经找到后，应该再花一点时间来确定其他还有什么原因导致问题的产生。您应该避免只找出单个原因。只有找到确定的原因越多，您解决问题的可能性就越大。因此要尽量找出可能的故障原因，按降序列出导致故障的可能原因，并从中找出最有可能的故障原因。

设计解决问题计划

只有当确定了导致问题产生的最有可能的原因时，才能制定一个操作计划。包括为了解决问题而计划使用的操作步骤。在确定操作步骤时。应尽量做到详细；这个计划越详细，按照这个计划执行的可能性就越大。一旦制定好计划，就要按步骤实施这个计划。

实施解决问题计划

当在实施操作计划时，以特别注意，每次只能作一个修改。如果修改后问题解决，那么应该将修改的结果进行分析并记入文档。如果修改没有成功，应该立即撤消这个修改。重要的是要按照制定的计划来进行操作。因为在实施计划中，有时由于某一步不行，很容易尝试新的方法。这样做的危害是很快就失去对原计划的跟踪线索，结果往往使情况变得更加槽糕。一旦发现原计划不可行，正确的方法是应该重新设计计划，然后实施新的计划。

另外，在实施操作计划时，应特别注意安全程序的执行。安全性是我们最担心的事情。不要或者尽量少开放网络，在解决问题时，也应该尽可能缩短放松安全性的时间。前者可以阻止不太精明黑客突破网络的企图，后者可以减少黑客在在网络安全性放松时攻击网络的可能性。

评估操作计划产生的结果

观察结果最简单的方法是用第一步中获得的数据来测试。问题的表现或者某些表现是否仍然存在呢？如在第一步中简明说明了存在的问题，那么就可以较容易地测定问题地表现是否存在。如果问题的某些表现已经解决，但其他的表现仍然存在，那么将解决方案记入文档，然后转入下一个操作步骤。

间歇性问题的测试并不是那么容易进行。有时要等到发生另一个故障时才能进行测试。在这种情况时，在最终确定问题之前，必须把对系统的修改记入文档，这是非常重要的。

重复操作过程

在完美无缺的环境中，根本不需要重复上面的操作过程，因为我们对问题的分析肯定能够指明存在的一个问题，也是唯一的问题。但在实际工作中我们很少能够做到完美无缺。当操作计划不能产生预期的结果时，首先应该撤消试图解决问题时所做的所有修改。如果保留这些修改，可能导致出现一些遗留问题。

下一步是搞清什么地方分析失败了。通过确定问题的性质来重新启动这个操作过程，这是非常重要的。对问题进行分析时，要对自己提出的所有假设多问几个为什么。重新确定问题的性质，当第二次设法解决问题时，要花费更多的时间去考察问题的细节，深入到问题的内部去看一看。如第一次解决问题时有些情况没有注意到，应该确保第二次解决问题时不要犯与第一次同样的错误。