用debug做思科路由交换机故障诊断.doc

用debug做思科路由交换机故障诊断（一） 2009-03-15 14:18一般来说对路由器和交换机的故障诊断，只用一个“show”命令是远远不够的。而debug命令往往能够帮助我们看清楚背后的故障原因。这篇文章主要介绍一下如何利用debug来进行常规的故障诊断。为什么debug命令如此有效？Cisco IOS show命令能够告诉你一个有关你的路由交换设备的基本信息，但是它不能告诉你全部信息。举个例子，show 没有办法告诉你一条路由是什么时候加入或者从路由表中删除的，为什么ISDN线路故障了，一个数据报文是否真的从路由器发出去了，或者指出收到了哪种ICMP错误信息。而上述的这些信息debug可以毫无保留的呈现给你。debug除了可以提供比show更多的信息之外，它提供的的实时（或者叫做动态）信息也是show无法比拟的。反观show无非是抓取特定时间片信息将结果反应到你的控制台上（可以称之为静态结果）。动态信息对我们故障分析的帮助无疑更有帮助。如何使用debug我们举一个例子，通过debug模式来看RIPRouter# debug ip RIPRIP protocol debugging is on我们可以用这个命令来看debugging是否启用：Router# show debugRIP protocol debugging is on任何类型的debug启用信息会被发送到Cisco loging system定义的地方，同时会被加入到路由器的(缓存)buffered log或者syslog server。看一下各种输出类型：Router# show loggingSyslog 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 loggedLog 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 upRouter#控制台会显示RIP更新的信息：*Jun 9 21:13:56.471: RIP: sending v1 update to 55 via FastEthernet0/0 () *Jun 9 21:13:56.471: RIP: build update entries - suppressing null update *Jun 9 21:14:22.519: RIP: sending v1 update to 55 via FastEthernet0/0 () *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。用debug做思科路由交换机故障诊断（二）2009-03-15 14:21下面开始正式介绍10种Cisco IOS debug 方式。10. Debug all显然，最危险的debug 命令就是debug all了。它有可能把路由器直接搞崩溃掉。当然执行之前，系统会要求一个确认信息。为了满足你的好奇心，列表 Listing C 列举了这条命令的输出。9. Debug ISDN 和 拨号设备Debug 在做Cisco路由器拨号配置故障排除的时候的用处。在具体工作当中，拨号配置往往很难一次就配置成功。比较好的方式是在配置IOS拨号的时候采用逐层配置，逐层测试的方法（OSI层）。当测试没有通过之后，debug就派上用场了: debug isdn events 调试所有ISDN的events. 这一条debug最好用在 q921 或者 q931之前。 因为那两条相对来说麻烦一点。debug isdn events 可能会有你想知道的所有信息。 debug isdn q921 针对Layer 2. debug isdn q931 针对Layer 3. debug dialer events 会告诉你有关拨号初始化或者结束的原因。这里是例子: 00:18:52: BRI0/0 DDR: Dialing cause ip (s=, d=)00:18:52: BRI0/0 DDR: Attempting to dial 835866100:19:22: BRI0/0:2 DDR: disconnecting call debug dialer packet 可以查看到什么数据包正在通过拨号接口以及包的来源和目的，还可以看到包是否被接口上dialer-list允许通过。例子： 00:39:24: BRI0/0 DDR: ip (s=, d=), 100 bytes, outgoing interesting (ip PERMIT)00:39:24: BRI0/0 DDR: ip (s=, d=), 100 bytes, outgoing interesting (ip PERMIT)00:39:24: BRI0/0 DDR: ip (s=, d=), 100 bytes, outgoing interesting (ip PERMIT)00:39:24: BRI0/0 DDR: ip (s=, d=), 100 bytes, outgoing interesting (ip PERMIT)00:41:09: BRI0/0 DDR: cdp, 273 bytes, outgoing uninteresting (no list matched)8. PPP authentication如果你出于安全目的在dialup line上配置了 PPP authentication，就可以通过用户名和密码来匹配或者阻断数据包的通过。如果不使用debug ppp authentication 就很难发现问题了。这是一个路由器上debug ppp authentication 密码出错的输出:00:32:30: BR0/0:1 CHAP: O CHALLENGE id 13 len 23 from “r200:32:31: BR0/0:1 CHAP: I CHALLENGE id 2 len 23 from “r100:32:31: BR0/0:1 CHAP: O RESPONSE id 2 len 23 from “r200:32:31: BR0/0:1 CHAP: I FAILURE id 2 len 26 msg is “Authentication failure”这是一个路由器上debug ppp authentication用户出错的输出:00:47:05: BR0/0:1 CHAP: O CHALLENGE id 25 len 23 from “r200:47:05: BR0/0:1 CHAP: I CHALLENGE id 19 len 23 from “r100:47:05: BR0/0:1 CHAP: O RESPONSE id 19 len 23 from “r200:47:05: BR0/0:1 CHAP: I FAILURE id 19 len 25 msg is “MD/DES compare failed”7. Debug topology packet这种方法可以对各OSI层进行诊断参考： Cisco Certification: Bridges, Routers, and Switches for CCIEs。根据OSI模型无论怎样的网络拓扑，比方说你可以使用debug去查看第二层使用了何种方式的封装 (当然你得保持接线正常)。假设你用了帧中继，但是你无法接受到数据包，在确认link是启用的情况下，你可以使用 debug frame-relay packet然后你可以尝试ping远端路由器的接口你就可能获得以下调试信息:01:03:22: Serial0/0:Encaps failedno map entry link 7(IP)这条信息告诉你帧中继的ip包封装失败了。不仅如此，它同时告诉你由于没有申明frame-relay map 而出错。修复之后，你会发现帧中继错误不再存在了。但是包仍有可能通不过，因此，你还需要对第三层进行debug:debug ip packet会得到：01:06:46: IP: s= (local), d=1, len 100, unroutable这就告诉你在第三层中没有路由可以让传输流过，然后你就可以添加路由彻底解决这个问题了。你还可以根据你的实际情况尝试以下几种方法进行调试： debug atm packet debug serial packet debug ppp packet debug dialer packet debug fastethernet packet 6. Debug crypto (IPSec 和 VPN 功能)当然IPSec和VPN范围太大了同时故障情况会很多，无法一一列举。我这里列举几个常用的IPSec和VPN的debug命令： debug crypto isakmp debug crypto ipsec debug crypto engine debug ip security debug tunnel 另外, debug ip packet, 对IPSec的诊断也很有帮助。如果你想知道更多关于IPSec主题的内容请参考 Ciscos IP Security Protocols Section。5. Debug IP routing例如在你的网络环境中存在路由问题，比如一条路由加入但是很快就被删除（flapping）你就可以利用debug ip routing。输出结果可能是这样的：01:30:56: RT: add 11/32 via 1, ospf metric 110/6501:31:13: RT: del 11/32 via 1, ospf metric 110/6501:31:13: RT: delete subnet route to 11/3201:31:13: RT: delete network route to 01:32:56: RT: add 11/32 via 1, ospf metric 110/6501:33:13: RT: del 11/32 via 1, ospf metric 110/6501:33:13: RT: delete subnet route to 11/3201:33:13: RT: delete network route to 这说明你的网络中存在路由环路的问题。另外就是可能在拨号接口或帧中继接口上的链路up马上又down掉了。4. Debug ip routing protocoldebug ip 有很多选项，可以通过debug ip ? 来获取，可以查看列表 Listing D。许多路由协议 (如, OSPF, EIGRP, IGRP, 和 BGP) 包含在了这张表格中。 每个协议又有它自己的很多扩展选项可以用debug。 (你可以使用debug ip routing protocol ? 来获取。) 例如debug ip ospf adjacency是唯一可以知道你的两条OSPF路由之间由于认证类型不匹配而没有形成交互的诊断方式。以下是输出结果，它告诉你认证类型布匹配:01:39:46: OSPF: Rcv pkt from 1, Serial0/0 : Mismatch Authentication type. Input packet specified type 0, we use type 2在这种情况下面要不是使用debug你可能会抓破脑袋。3. Debug list这事一条比较少用但比较有意思的命令。实际上这条命令什么也不调试。它为你下一条debug命令在你的一个接口上设置一个访问列表。 如:debug list 1debug dhcp detailDHCP client activity debugging is on for access list: 1 (detailed)2. 记录 access list 到 system 或 syslog你可以在一条访问列表的最后使用log 选项来记录被允许或者拒绝的数据包。相当于起到部分防火墙或者访问控制的作用。举例：首先，假设你只允许BGP在你的网络中传输然后希望跟踪其它的企图进入某链路的传输。配置例子：Interface Serial 0/0Access-group 100 inaccess-list 100 remark Begin Allow BGP IN and OUTaccess-list 100 permit tcp host host eq bgpaccess-list 100 permit udp any host gt 33000access-list 100 remark Endaccess-list 100 deny ip any any log如果你开启了“logging buffered”或者配置了syslog服务器，所有经过你的路由器的传输会被记录下来。在第二个例子里面，假设你希望建立一条访问列表某一类型的传输通过你的拨号接口。配置如下:Interface BRI 0/0Access-group 100 inAccess-group 100 outaccess-list 100 permit ip any any log如果你查看router的 log, 你会发现ICMP packet 和一个TCP packet通过了你的链路:02:03:43: %SEC-6-IPACCESSLOGDP: list 100 permitted icmp - (0/0), 1 packet02:06:25: %SEC-6-IPACCESSLOGP: list 100 permitted tcp (0) - (0), 1 packet1. Debug IP packet detail XXX (access list number)这一条命令可以象一个基本的sniffer/protocol分析工具利用访问列表去查看从源自（到达）某处的传输。为什么说是基本的抓包分析工具呢？因为它看不到包头。你能够利用访问列表来查看特定的主机、协议、端口或者网络。 当然它不是真正意义上的协议分析工具，但是它是IOS集成的一个特性，比别的工具相对来说使用起来方便快捷。下面的例子是一个记录所有通过你的路由器的Telnet包的配置。access-list 101 permit tcp any any eq telnetdebug ip packet detail 101IP packet debugging is on (detailed) for access list 101Listing E 总结了一些debug输出的示例。你可以从输出结果看到获取的ip 源、目的（地址、端口号）接口、sequence 号、acknowledgement 号, window 尺寸, 和 TCP 通讯标志 (SYN, ACK, FIN)。This post was written by:不唠嗑*CPU及内存的使用率在50%以上时，慎用debug命令*附：Listing CListing CRouter#deb all This may severely impact network performance. Continue? (yes/no): yesAll possible debugging has been turned onRouter#Router#show debugdebug all is in effect. Command parser: Parser ambiguity debugging is off Help message debugging is off Parser mode debugging is off Parser interface range debugging is off Parser aliases debugging is off Privilege level debugging is off Parser HTTP processing debugging is off Parser Cache debugging is off Frame Relay switching debug interval is 1 secondsUDPtn debugging is offLPD Printer debugging is off (detailed)IP multicast: IP multicast fast-switching debugging is on IP multicast routing debugging is on IGMP debugging is on CGMP debugging is on RGMP debugging is on DVMRP debugging is on PIM debugging is on PIM DF debugging is on PIM ATM debugging is on PIM BSR debugging is on SD debugging is on PIM Auto-RP debugging is on MSDP debugging is on URD debugging is on Heartbeat debugging is on IP Multicast tagswitching debugging is on PIM multicast tagswitching debugging is onAT/EIGRP: AT/EIGRP Event Logging debugging is offAppleTalk Remote Access: ARAP MNP4 debugging is on ARAP V.42bis debugging is on ARAP internal packet debugging is on ARAP memory debugging is onLDAP:connect debbuging is onbind debbuging is onber debbuging is onreceivedata debbuging is onrequest debbuging is onreferrals debbuging is onerror debbuging is on DLSw: DLSw Core debugging is off DLSw Reachability debugging is off DLSw Local Circuit debugging is offDLSw reachability debugging is on at event level for all protocol trafficDLSw core message debugging is onDLSw core state debugging is onDLSw core flow control debugging is onDLSw core xid debugging is on DLSw Local Circuit debugging is onSNA: SNA activation debugging is on for all PUs SNA packet debugging is on for all PUs SNA state change debugging is on for all PUs SNA trace debugging is on for all PUs SNA alert debugging is on for all PUs NCIA: Debug client all is onNCIA: Debug server is onNCIA: Debug circuit all is onBSTUN: BSTUN event debugging is on BSTUN packet debugging is on BSTUN packet display size for debugging is 20BSC: BSC event debugging is on BSC packet debugging is on BSC diagnostic debugging is on BSC packet display size for debugging is 20ASPP: ASPP event debugging is on ASPP packet debugging is on ASPP packet display size for debugging is 20MGCP: Media Gateway Control Protocol input packets in hex value debugging is offRudpv1: Application debugging is enabledRudpv1: Performance debugging is enabledRudpv1: Retransmit/softreset is enabledRudpv1: Segment debugging is enabledRudpv1: Signal debugging is enabledRudpv1: State debugging is enabledRudpv1: Timer debugging is enabledRudpv1: Transfer state debugging is enabledBSM:All debuuging turned on at the session level ISDN events debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 - 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ISDN Q921 packets debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 - 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ISDN L2 Socket Process packets debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 - 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 - 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ISDN API event debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 - 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ISDN backhaul event debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 - 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -X.25: X.25 special event debugging is off X.25 encapsulation debugging is off X.25 switch debugging is off X.25 over FR (Annex-G) debugging is off Always On/Direct ISDN events debugging is offRadius protocol debugging is off (detailed)Voice Telephony session debugging is onVoice Telephony dsp debugging is onVoice Telephony error debugging is onVoice Telephony stats debugging is onVoice Telephony tone generation debugging is onTSP call debugging is onTSP port debugging is onTSP error debugging is onTSP ROSE ASN debugging is onCCH323 SPI: H225 State Machine tracing is enabledCCH323 SPI: H245 State Machine tracing is enabledCCH323 SPI: RAS State Machine tracing is enabledCCH323 SPI: RTP packet tracing is enabledCCH323 SPI: Session tracing is enabledCCH323 SPI: CCH323 Error debug is enabledCCH323 SPI: CCH323 Rawmsg debug is enabledCCH323 SPI: CCH323 H450 debug is enabledRTP SPI error tracing is enabled.RTP SPI function in/out tracing is enabled.RTP SPI Session tracing is enabledTranslation debug detail is onTranslation debug min is onCCSIP SPI: SIP Call Statistics tracing is enabledCCSIP SPI: SIP Call Message tracing is enabledCCSIP SPI: SIP Call State Machine tracing is enabledCCSIP SPI: SIP Call Events tracing is enabledSIP : SIP error debug tracing is enabledQoS Module : Function Trace Debugging is enabled QoS Module : Events Debugging is