网络检修过程中最困难的部分往往是你首先需要发现问题所在。笨系列文章从头到尾讲述的都是一个高效的网络管理系统(NMS)如何能够使你获悉网络的状态信息和运转情况。我们已经讲述了网络管理系统如何使你获悉网络发生了故障或者网络性能开始下降。我们还讨论了网络管理系统如何协助你维护网络设备稳定、一致的配置。这样，即便知道网络存在问题，我们也可以通过有效地使用网络管理系统来解决故障检修过程中最困难的这一部分。
接下来的难题就是搞清楚问题到底是什么。可以毫不夸张的说，网络管理系统不仅可以在问题出现时进行报警，还能够协助你对问题进行确认。但是，有时候触发报警的事件或者条件并不一定就是问题的根源所在。如果你收到报警说网络链路不能满足性能服务等级协议(SLA)的要求，你并不能总是立即知道引起性能下降的原因。
一旦你知道问题的根源所在，通常的做法就是用google搜索解决方案。但是，查找问题的根源以及修复这些问题可能需要花费大量的时间。正因为如此，网络管理员在进行故障检修时才对我们的方案情有独中。当问题发生时，能否快速、有效地进行故障检修就能将管理老手和菜鸟区分开来。不管你的故障检修经验水平如何，拥有一套好的工具以及一种好的技术是非常重要的。接下来的章节将帮助你成为一个优秀的网络维修专家。
当你的网络出现问题时，你首先会做的是什么?你会ping网络设备以查看该设备是否正常运行并且有所响应吗?或者，你会一头扎进网络管理房来检查LED指示灯是否仍然闪烁绿色，还是已经变成了红色吗?又或者，你会联系求救的用户或者登录到通报故障的网络管理系统来查找更多的有关问题的信息吗?
在这些操作当中，没有哪一种比另外的更好。对那些首先ping设备的人来说，你立即就可以获得一个底层的认识，即该设备能否和你的工作站通信。对那些一头扎进网络管理房的人来说，你可以很快发现接口是否正在显示错误或者已经当机。对那些联系用户或者与通知代理一同工作的人来说，你可以迅速得到触发故障告警错误的第一手资料。
在每一种情况下，进行故障检修的最重要的部分就是开发一种有效的技术。不管网络中的问题是什么，你都会发现，拥有一种好的技术来发现问题有助于你快速确认问题的根源所在，以便你找到有效的解决方案。
可以这么说，一个好的故障检修专家是一个快速的故障检修专家。整篇你都会注意到，故障检修过程，以及对工具的讨论，都是为了协助你快速地找到解决方案。使用OSI模型作为故障检修的框架
一个有助于你构造对已知网络问题进行响应的通用的故障检修框架是国际标准化组织(ISO)提出的开放系统互连(OSI)模型。如果你和网络设备一起工作已经有一段时间的话，你可能对OSI模型已经熟悉。它是一个囊括了当今很多网络和大多数网络协议的七层框架。你以前可能没有用到的是把它当作一种故障检修指南来对网络中的未知问题进行分类。
图 SI模型是协助网络检修人员识别网络问题的一种理想的框架无需探究有关该模型的历史和使用的太多细节，让我们来看一下你可以如何将OSI模型扩展成一个可用于问题隔离的框架。图4.1显示了OSI模型的七层结构以及与每一层相关的一些典型问题。让我们按照从下到上的顺序来讨论每一层：
物理层 典型问题包括构成网络的物理连接的断裂。断开的网络连接，电缆和连接器问题和由硬件引起的禁止电流在设备之间的传送问题都是物理层的一些典型问题。
数据链路层 我们暂不讨论纯粹的电学问题，而将注意力转移到接口本身的配置。数据链路问题常常和地址解析协议(ARP)问题有关，该协议负责将IP地址转换成MAC地址。网络设备之间速率和工作模式的不匹配或者过多的硬件接口错误都会引发这些问题。而设备操作系统(OS)接口的错误配置或者无线连接的干扰同样会导致数据链路层出现问题。
网络层 我们从网络遍历问题开始说起。网络分组无法在从源地址到目的地址的过程中进行正确选路往往会造成网络层问题。这可能和不正确的IP寻址或者网络中的IP地址复制有关。网络中的数据或者ICMP分组路由问题以及协议错误也有可能导致问题的发生。在极端情况下，外部攻击同样有可能造成网络设备的错误从而导致网络层出现问题。
传输层 传输层问题一般出现在以太网中的TCP或者UDP分组上。这些问题可能和过量重传错误或者分组分裂有关。没有单独的一种问题能够导致网络性能完全下降。该层上的问题比较难于追踪，因为不像底层出现的问题，传输层问题通常不会导致连接的完全丢失。此外，传输层问题还经常与IP端口的流量拥塞有关。如果你能够ping通服务器，但是不能通过已知端口进行连接，这有可能就是一个传输层问题。
会话层、表示层和应用层 这三层经常被放到一起讨论，因为最近有关OSI的解释趋向于淡化这三层之间的分隔。这三层的故障检修过程包括与应用有关的各种问题。
这些应用问题可能包括DNS、NetBIOS问题或者其它一些存在于OS中的解析、应用问题，又或者是高层协议失效或者错误配置问题。一些典型的高层协议有HTTP协议、SMTP协议、FTP协议和其它一些典型的“使用网络”而不是“运行网络”的协议。另外，一些专门的外部攻击(如中间人攻击)也会造成这些层次上的问题。
网络问题可能而且确实发生在模型的任意一层上。因为网络管理员对该模型非常了解，所以它自然就成了各种网络管理员用来解决问题的一种有效的工具。如果你曾经和使用如此语言-“这好像是第四层的问题”-的网络管理员一起工作，你马上就可以知道问题可能发生的大体区域(传输层)。
你会听到一些有经验的网络管理员经常使用层次号来指代问题的位置。例如，当你听到“那在第三层”，就表示IP连接问题。第四层揭示的是网络端口关闭引起的问题。有趣的是，网络管理员喜欢把系统而不是网络出现的问题称为“第七层”问题。让我们探讨一下在使用OSI模型对问题进行隔离的过程中可以使用的三种不同的方法。
三种不同的方法
使用OSI模型作为故障检修框架的网络管理员一般使用下列三种方法中的一种：自下而上(Bottom-Up)、自上而下(Top-Down)和自中间而两端(Divide-and-Conquer)。对某一个特定问题，他们会依据问题的明显程度和他们的经验来选择其中一种方法。基于问题的类型，每一种方法都有它的用武之地。让我们一个个来讨论。
自下而上(Bottom-Up)
简单来说，自下而上的方法就是，网络管理员从OSI模型的底部开始，逐步穿过各个层次，直到找到问题的根源所在。使用自下而上方法的网络管理员一般从检查物理层问题开始，首先，确定网络连接是否断裂，其次，查看网络接口配置和误差率，再次，检查路由、分段和端口阻塞等IP和TCP/UDP错误，最后，查看各个应用错误。
这种方法最适合于网络完全崩溃或者具有大量底层错误的情形。当问题特别复杂时，这种方法也是最佳选择。在复杂的问题中，故障检测程序往往无法给网络管理员提供足够的调试数据以便对问题进行分析。因此，聚焦于网络的方法是最佳的。
自上而下(Top-Down)
自上而下的方法于自下而上的方法正好相反，网络管理员首先从OSI模型的顶端开始，查看出现故障的程序并设法跟踪程序出现故障的原因。这种方法最适合于网络状态良好，网络中新的应用或者应用配置正在完成的时候。网络管理员可以首先确保应用的正确配置，然后往下保证全IP连接和适当的端口处于开放状态以确保程序的正常运行。一旦所有的上层问题被解决，就可以回头检查网络功能是否正常。正如先前所述，这种方法一般用于网络功能正常，但是正在引入新的网络应用或者正在对现存应用进行重新配置的情况。
自中间而两端(Divide-and-Conquer)
自中间而两端的方法是对“内脏感觉”方法的一种富有想象力的命名。这种方法一般被对网络和可能出现的问题有较深理解的有经验的网络管理员所使用。自中间而两端的方法需要网络管理员具对问题出现的地方有一种直观的感觉，首先从你认为问题可能出现的那一层开始，然后从该位置逐步扩展到模型的两端。这种方法还可以用于解决以前遇到过的一些小问题。
然而，这种方法经常会因为没有足够的科学依据而无法正确地诊断比较困难的问题而失败。如果问题在本质上非常复杂，那么自中间而两端的方法可能就无法有效地追踪问题所在。
图 据问题的类型，选择自下而上、自上而下或者自中间而两端方法中最有效的一种来隔离问题的根源
不管你使用的是那种方法，只有当你充分了解了你的网络和它的特质，你才能考虑选择使用一种结构化的方法作为故障检修技术。尽管使用结构化的方法可能会增加解决问题的时间，但是它将彻底追查问题根源所在，而不会由于遗漏一些关键问题而日后对网络“修修补补”。
只有当你对网络以及故障检修技术有了坚实的基础，才建议你使用自中间而两端的方法。这种方法常常只能应付一些表面的网络问题而不能解决实际的根源问题。
让我们暂时放下故障检修的一般概念，开始谈一下我们可以使用的进行故障检修的一些工具。
