网络检修过程中最困难的部分往往是你首先需要发现问题所在。笨系列文章从头到尾讲述的都是一个高效的网络管理系统(NMS)如何能够使你获悉网络的状态信息和运转情况。我们已经讲述了网络管理系统如何使你获悉网络发生了故障或者网络性能开始下降。我们还讨论了网络管理系统如何协助你维护网络设备稳定、一致的配置。这样,即便知道网络存在问题,我们也可以通过有效地使用网络管理系统来解决故障检修过程中最困难的这一部分。
接下来的难题就是搞清楚问题到底是什么。可以毫不夸张的说,网络管理系统不仅可以在问题出现时进行报警,还能够协助你对问题进行确认。但是,有时候触发报警的事件或者条件并不一定就是问题的根源所在。如果你收到报警说网络链路不能满足性能服务等级协议(SLA)的要求,你并不能总是立即知道引起性能下降的原因。
一旦你知道问题的根源所在,通常的做法就是用google搜索解决方案。但是,查找问题的根源以及修复这些问题可能需要花费大量的时间。正因为如此,网络管理员在进行故障检修时才对我们的方案情有独中。当问题发生时,能否快速、有效地进行故障检修就能将管理老手和菜鸟区分开来。不管你的故障检修经验水平如何,拥有一套好的工具以及一种好的技术是非常重要的。接下来的章节将帮助你成为一个优秀的网络维修专家。
当你的网络出现问题时,你首先会做的是什么?你会ping网络设备以查看该设备是否正常运行并且有所响应吗?或者,你会一头扎进网络管理房来检查LED指示灯是否仍然闪烁绿色,还是已经变成了红色吗?又或者,你会联系求救的用户或者登录到通报故障的网络管理系统来查找更多的有关问题的信息吗?
在这些操作当中,没有哪一种比另外的更好。对那些首先ping设备的人来说,你立即就可以获得一个底层的认识,即该设备能否和你的工作站通信。对那些一头扎进网络管理房的人来说,你可以很快发现接口是否正在显示错误或者已经当机。对那些联系用户或者与通知代理一同工作的人来说,你可以迅速得到触发故障告警错误的第一手资料。
在每一种情况下,进行故障检修的最重要的部分就是开发一种有效的技术。不管网络中的问题是什么,你都会发现,拥有一种好的技术来发现问题有助于你快速确认问题的根源所在,以便你找到有效的解决方案。
可以这么说,一个好的故障检修专家是一个快速的故障检修专家。整篇你都会注意到,故障检修过程,以及对工具的讨论,都是为了协助你快速地找到解决方案。
使用OSI模型作为故障检修的框架
一个有助于你构造对已知网络问题进行响应的通用的故障检修框架是国际标准化组织(ISO)提出的开放系统互连(OSI)模型。如果你和网络设备一起工作已经有一段时间的话,你可能对OSI模型已经熟悉。它是一个囊括了当今很多网络和大多数网络协议的七层框架。你以前可能没有用到的是把它当作一种故障检修指南来对网络中的未知问题进行分类。
图4.1 OSI模型是协助网络检修人员识别网络问题的一种理想的框架
无需探究有关该模型的历史和使用的太多细节,让我们来看一下你可以如何将OSI模型扩展成一个可用于问题隔离的框架。图4.1显示了OSI模型的七层结构以及与每一层相关的一些典型问题。让我们按照从下到上的顺序来讨论每一层:
物理层 典型问题包括构成网络的物理连接的断裂。断开的网络连接,电缆和连接器问题和由硬件引起的禁止电流在设备之间的传送问题都是物理层的一些典型问题。
数据链路层 我们暂不讨论纯粹的电学问题,而将注意力转移到接口本身的配置。数据链路问题常常和地址解析协议(ARP)问题有关,该协议负责将IP地址转换成MAC地址。网络设备之间速率和工作模式的不匹配或者过多的硬件接口错误都会引发这些问题。而设备操作系统(OS)接口的错误配置或者无线连接的干扰同样会导致数据链路层出现问题。
网络层 我们从网络遍历问题开始说起。网络分组无法在从源地址到目的地址的过程中进行正确选路往往会造成网络层问题。这可能和不正确的IP寻址或者网络中的IP地址复制有关。网络中的数据或者ICMP分组路由问题以及协议错误也有可能导致问题的发生。在极端情况下,外部攻击同样有可能造成网络设备的错误从而导致网络层出现问题。
传输层 传输层问题一般出现在以太网中的TCP或者UDP分组上。这些问题可能和过量重传错误或者分组***有关。没有单独的一种问题能够导致网络性能完全下降。该层上的问题比较难于追踪,因为不像底层出现的问题,传输层问题通常不会导致连接的完全丢失。此外,传输层问题还经常与IP端口的流量拥塞有关。如果你能够ping通服务器,但是不能通过已知端口进行连接,这有可能就是一个传输层问题。
会话层、表示层和应用层 这三层经常被放到一起讨论,因为最近有关OSI的解释趋向于淡化这三层之间的分隔。这三层的故障检修过程包括与应用有关的各种问题。
[1] [2] 下一页