环环相扣排除故障 使网络快速恢复运行

　　每一次网络发生故障时，上级管理部门关心的是如何使网络快速恢复运行，因为网络不能正常工作，公司就会因此而遭受损失，并且这些损失永远都无法再得到弥补。

　　但我们今天在这里要讨论的问题并不是如何防止网络发生各种故障，而是另外一个话题。当你的网络发展到很大规模时，如果当初在建网时候没有很好的规划，你就会发现你的网络拓扑已经变得非常复杂，网络经常会出现不稳定状态。这时候最主要的问题是如何能迅速使网络恢复运行,并且能使网络在长时间内保持稳定的运行。

　　但故障排除讨论起来是很模糊的，在问题还没有发现之前，我们一直在做假设。当网络出现问题的时候，作为网管员的你，应该有一个网络的总拓朴图，比如你都用了什么设备，路由器、交换机、HUB等等是什么厂家的？不同厂家的配置也不同。还有你的路由器的连接情况，安装了几个模块？运用了什么样的路由协议？它的系统版本号是多少？有没有访问列表？各个网络设备的IP地址是多少？它们以前所有的配置等等问题。网络出现故障通常是以下几点：

　　1、物理层有没有问题，设备连接情况、硬件、线路本身有没有问题。

　　2、数据链路层有没有问题，如网络设备的接口配置有没有问题。

　　3、网络层有没有问题，如是不是网络协议配置有问题或操作错误、时钟有没有对。

　　4、性能有没有问题，有没有拥塞情况，它们都会引起传输层超时等问题。

　　5、应用程序有没有问题，或者路由器、交换机或其它机器本身的操作系统有没有题。

　　网络通常情况都是物理层出现问题，所以从物理层向上进行排除是比较合理的，也许这并不能使问题解决得非常巧妙，但是逐层检查就能够清楚地看到问题本来的面目了。不过解决问题需要三思而后行，在很多时候有一些很容易的情况，因为太仓促行事而把事情弄成一团糟。匆忙行事修改网络中的配置，很容易引起其它问题的出现，将原来的状态搅得混乱不堪，进行故障排除时，要记住一点，就是你改变了什么，都要用纸记下来，一次只改变一个变量，看看这种改变对目前有没有影响，有的话是什么样的情况要记录下来，没有的话是什么样的情况也要记录下来，然后再回到原样。在你想做改动这前，一定要想：改了以后能不能恢复到原来的状态呢？此外还要考虑其他一些细节如，你发出了一个调试命令，对处理能力、性能有没有造成影响，如果你能坚持这些做法，那么你在处理问题时就会得心应手，不可能把问题变得更复杂化了。

　　收集所有关于网络方面的信息，再对所发生的问题进行分析。所有的产品都有它自己的操作系统，如Cisco公司的IOS，它在这些方面做得比较好的一面是：用show和debug命令比较直观，你可以看到各种路由器信息。然而你必须知道，在什么样的情况下用什么样的命令来获得你所需要的信息，这就是一个技巧。Show命令的输出与debug命令的输出之间有很大区别，show命令能够为你提供某时间设备状态视图，但是debug命令能够展示一个时期内某个设备的变化情况，你想要了解你当前路由器与交换机运行的整个情况，那你须同时使用这两个命令。Show命令与debug命令之间还有一个很大的区别，这两个命令对系统性能的影响有所不同，show命令通常不会影响运行的性能，debug命令则会对系统的运行性能产生影响，而且show命令运行完成后就会自动结束，但debug命令要等你把它停止才结束，所以当你打开一个debug命令的进程时，别忘了结束它的进程。

　　如：core1#debug serial interface 你可以用 core1# no debug serial interface 或者用：core1#no debug all 。

　　下面我就先介绍一些命令，（我会在下一次全面的讲解各种命令）。 路由器的接口信息，用“ show ip interface brief ”看路由器所有接口的信息，当然你也可以用简写比如上面这条信息，也可以用“ s ip int b ”这样来加快你的操作能力，不过这些简写的命令只有新版的IOS才支持。把收集的信息与所发现的问题进行分析。你可以用各种 SHOW命令来查看路由器，比如：show version show flash show processes cpu show processes memory show buffers show stacks show controllers (参数) E1、FastEthernet、T1、async，等各种show命令，都可以告诉你当前的路由信息。DEBUG命令，这是个调试命令，debug命令的输出将优先于所有其他的网络信息，而且debug命令会对路由器的性能产生影响，因此在进行调试操作时应该格外的小心，以保在调试过程中不会导致其他的问题出现。在使用debug命令的时候，特别要小心不能用debug all。一般情况下，debug的信息都是发送到控制台，但是你可以把这些信息发送到其它的地方，比如你的日志服务器，但你必须在路由器上配置一下，比如： core1(config)#enable message logging 。然后我们再配置日志服务器，接着必须使用这个命令，使debug的信息可以发送到你的日志服务器上，用 core1(config)#logging on 。当然你也可以把一些信息安排为可以在控制台看到，一些不可以在控制台看到。你也可以把日志设置为不同的等级，在路由器中等级越高，输出的信息就越多。比如将等级设置为0，那只有在系统紧急情况才可以接收信息，信息的等级越高所需路由器的CPU处理能力就越大。

　　表（一）就可以看出记录不同等级的系统日志的定义。

　　信息等级 关键字 描述 系统日志

　　0 Emergencies 系统已经到了不稳定的状态 LOG_EMERG

　　1 Alerts 应该立即采取措施 LOG_ALERT

　　2 Critical 存在非常危急的信息 LOG_CRIT

　　3 Errors 存在不太危急的错误 LOG_ERR

　　4 Warnings 存在需要要警惕的信息 LOG_WARNING

　　5 Notification 存在值得重视的信息 LOG_NOTICE

　　6 Informational 仅供参考的信息 LOG_INFO

　　7 Debugging 这些是调试信息 LOG_DEBUG

　　你若想限制一些信息记录到控制台的话，你可以用logging console这个命令，它可以限制什么样的信息在控制台看到，什么样的传到日志服务器上去。比如你想把一条存在错误的信息记录到控制台的话，你可以用：core1(config)#logging console 3 这个命令，你也可以用关键字来配置。比如： core1 (config)#logging console errors 这个命令。还可以把这些信息存在路由器自己的缓存中，你可以用core1(config)#logging buffered ，这个缓存是从你的内存中划过来的，它的大小是有限的，它取值范围是(4096-2147483647)。通常取(4096-102400)这个范围。然后我们可以配置一个远程或者局域网内的一个日志服务器，core1(config)#logging 10.1.0.123 也可以建立多个日志服务器，比如：core1(config)#logging 192.168.10.123。

　　你可以把不同的日志文件发到不同的服务器上，如: core1(config)#logging trap log_debug 10.1.0.123 记住这个log_debug的参数不是随更改的，要按上面表里面的项来配置。