用debug做思科路由交换机故障诊断（一）

 一般来说对路由器和交换机的故障诊断，只用一个“show”命令是远远不够的。而debug命令往往能够帮助我们看清楚背后的故障原因。这篇文章主要介绍一下如何利用debug来进行常规的故障诊断。

 

为什么debug命令如此有效？

 

Cisco IOS "show"命令能够告诉你一个有关你的路由交换设备的基本信息，但是它不能告诉你全部信息。举个例子，show 没有办法告诉你一条路由是什么时候加入或者从路由表中删除的，为什么ISDN线路故障了，一个数据报文是否真的从路由器发出去了，或者指出收到了哪种ICMP错误信息。而上述的这些信息debug可以毫无保留的呈现给你。

debug除了可以提供比show更多的信息之外，它提供的的实时（或者叫做动态）信息也是show无法比拟的。反观show无非是抓取特定时间片信息将结果反应到你的控制台上（可以称之为静态结果）。动态信息对我们故障分析的帮助无疑更有帮助。

 

如何使用debug

 

我们举一个例子，通过debug模式来看RIP

Router# debug ip RIP

RIP protocol debugging is on

 

我们可以用这个命令来看debugging是否启用：

Router# show debug

RIP protocol debugging is on

 

任何类型的debug启用信息会被发送到Cisco loging system定义的地方，同时会被加入到路由器的(缓存)buffered log或者syslog server。看一下各种输出类型：

Router# show logging

Syslog logging: enabled (1 messages dropped, 3 messages rate-limited,

                0 flushes, 0 overruns, xml disabled, filtering disabled)

    Console logging: level debugging, 8 messages logged, xml disabled,

                     filtering disabled

    Monitor logging: level debugging, 0 messages logged, xml disabled,

                    filtering disabled

    Buffer logging: level warnings, 2 messages logged, xml disabled,

                    filtering disabled

    Logging Exception size (4096 bytes)

    Count and timestamp logging messages: disabled

    Trap logging: level informational, 12 message lines logged

Log Buffer (51200 bytes):

*Jun 9 20:56:49.195: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Jun 9 20:56:49.231: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

Router#

控制台会显示RIP更新的信息：

*Jun 9 21:13:56.471: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (.1)

 

*Jun 9 21:13:56.471: RIP: build update entries - suppressing null update

 

*Jun 9 21:14:22.519: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (.1)

 

*Jun 9 21:14:22.519: RIP: build update entries - suppressing null update

 

需要提醒的是，只能短时间内开启debug来获取一定时间的信息，因为debug会造成路遇器性能的下降。可以使用 undebug all 来关闭debug。

 

三种使用debug时的错误

 

使用debug是一个危险的动作，甚至有经验的管理员使用它时也会失误。

 

第一常见的错误是当你离开生产环境的时候忘记关闭调试模式。因为有时候我们集中精力解决问题，当我们解决问题之后，就有可能忘记没有关闭debug模式。

 

第二常见的错误是忽略同时发出的大量调试命令对路由器产生的影响。记住，路由器的工作是转发数据包，而不是监察过程和产生调试信息。举例来说，在你的路由器存在数据包的某些问题，所以使用debug调试IP数据包。接着你决定要查看RIP协议方面的一些(事件)events。现在，你有两个单独的调试报表正在处理和发送到控制台。debug比比其他的网络传输具有更高的优先级，所以，不用说，这些debug可能危及您的路由器的性能。

 

第三常见的错误是在一个生产环境的路由器上使用debug all 命令或debug ip packet detail。这些命令都可以令负载过重的路由器崩溃。 幸运的是，在正式启动调试模式之前有一个“确定”这样提示的提示。应该在开始调试命令之前现在某个测试路由器上跑一下这些debug命令。

 

假设我们配置好的Cisco路由器能够象时钟一样稳定的工作或者说极少需要人为去做一些故障排除。那么这样就可称之为理想状态。

 

但是，如果你的路由器出了故障，而你不得不快速准确地拿出一个解决方案。这就是我们为什么要用学会用debug去做故障排除。

 

这篇文章的对象是没有使用过debug做Cisco故障排除。但是你如果有这方面的经验，看我的介绍能不能给你一些提示去尝试之前没有用到过的方法。

 

在开始介绍Cisco IOS debug 10 招之前这里有些提示和说明：

• 我介绍的方法是部分debug的用法，但并不能涵盖所有的用法。事实上debug的用法有很多，这里不能一一列举。 Listing A 表格列举了所有在IOS 12.2 版本中你能用到的参数或子命令。 可能里面的一部分并不是很常用。这里将介绍一部分常用的debug命令。
• 使用Cisco IOS debug必须很小心，在你使用debug之前最好在测试路由器上做一些测试，最后再在生产环境中使用。如果你参考本文内容不慎将公司的路由器搞瘫而被开，本人不承担任何责任，哈哈。
• 默认情况下，Debug消息会发送到控制端但不会发送到任何log。如果要记录debug log,你必须在 全局配置模式里开启logging buffered。开启之后你可以用show logging来验证一下。这个在前一篇文章里面有所介绍。输出结果可以参考表格 Listing B. 一共有三种logging:console, monitor, 和 buffer. 也有不同level的logging。需要更多信息点击here。
• 如果你需要将debug输出到终端界面而不是控制台，需要使用终端监控命令。
• 你也可以设置“conditional debugging” 去调试符合特定条件的应用。参考Cisco官方文档Troubleshooting and Fault Management 。
• 如果debug信息输出太多，你需要停止调试，最快捷的方法是 un all。