Chinaunix首页 | 论坛 | 博客
  • 博客访问: 863786
  • 博文数量: 275
  • 博客积分: 3904
  • 博客等级: 中校
  • 技术积分: 4605
  • 用 户 组: 普通用户
  • 注册时间: 2012-04-17 21:10
文章分类

全部博文(275)

文章存档

2014年(9)

2013年(124)

2012年(142)

分类: 系统运维

2013-08-21 11:21:40

一般来说对器和的诊断,只用一个“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.1.1.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.1.1.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去做故障排除。

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

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=1.1.1.2, d=1.1.1.1)
00:18:52: BRI0/0 DDR: Attempting to dial 8358661
00:19:22: BRI0/0:2 DDR: disconnecting call

    debug dialer packet 可以查看到什么数据包正在通过拨号接口以及包的来源和目的,还可以看到包是否被接口上dialer-list允许通过。例子:

00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 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 “r2″
00:32:31: BR0/0:1 CHAP: I CHALLENGE id 2 len 23 from “r1″
00:32:31: BR0/0:1 CHAP: O RESPONSE id 2 len 23 from “r2″
00: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 “r2″
00:47:05: BR0/0:1 CHAP: I CHALLENGE id 19 len 23 from “r1″
00:47:05: BR0/0:1 CHAP: O RESPONSE id 19 len 23 from “r2″
00: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 failed–no map entry link 7(IP)

这条信息告诉你帧中继的ip包封装失败了。不仅如此,它同时告诉你由于没有申明frame-relay map 而出错。修复之后,你会发现帧中继错误不再存在了。但是包仍有可能通不过,因此,你还需要对第三层进行debug:

debug ip packet

会得到:
01:06:46: IP: s=1.1.1.2 (local), d=11.11.11.11, 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主题的内容请参考 Cisco’s IP Security Protocols Section。

5. Debug IP routing
例如在你的网络环境中存在路由问题,比如一条路由加入但是很快就被删除(flapping)你就可以利用debug ip routing。

输出结果可能是这样的:
01:30:56: RT: add 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:31:13: RT: del 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:31:13: RT: delete subnet route to 111.111.111.111/32
01:31:13: RT: delete network route to 111.0.0.0
01:32:56: RT: add 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:33:13: RT: del 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:33:13: RT: delete subnet route to 111.111.111.111/32
01:33:13: RT: delete network route to 111.0.0.0

这说明你的网络中存在路由环路的问题。另外就是可能在拨号接口或帧中继接口上的链路up马上又down掉了。

4. Debug ip {routing protocol}
debug 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 12.12.12.11, Serial0/0 : Mismatch Authentication type. Input packet specified type 0, we use type 2

在这种情况下面要不是使用debug你可能会抓破脑袋。

3. Debug list
这事一条比较少用但比较有意思的命令。实际上这条命令什么也不调试。它为你下一条debug命令在你的一个接口上设置一个访问列表。 如:
debug list 1
debug dhcp detail
DHCP client activity debugging is on for access list: 1 (detailed)

2. 记录 access list 到 system 或 syslog
你可以在一条访问列表的最后使用log 选项来记录被允许或者拒绝的数据包。相当于起到部分防火墙或者访问控制的作用。举例:

首先,假设你只允许BGP在你的网络中传输然后希望跟踪其它的企图进入某链路的传输。配置例子:

Interface Serial 0/0
Access-group 100 in

access-list 100 remark Begin — Allow BGP IN and OUT
access-list 100 permit tcp host 1.1.1.1 host 2.2.2.2 eq bgp
access-list 100 permit udp any host 2.2.2.2 gt 33000
access-list 100 remark End
access-list 100 deny ip any any log

如果你开启了“logging buffered”或者配置了syslog服务器,所有经过你的路由器的传输会被记录下来。

在第二个例子里面,假设你希望建立一条访问列表某一类型的传输通过你的拨号接口。配置如下:
Interface BRI 0/0
Access-group 100 in
Access-group 100 out

access-list 100 permit ip any any log

如果你查看router的 log, 你会发现ICMP packet 和一个TCP packet通过了你的链路:
02:03:43: %SEC-6-IPACCESSLOGDP: list 100 permitted icmp 1.1.1.2 -> 1.1.1.1 (0/0), 1 packet
02:06:25: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet

1. Debug IP packet detail XXX (access list number)
这一条命令可以象一个基本的sniffer/protocol分析工具利用访问列表去查看从源自(到达)某处的传输。为什么说是基本的抓包分析工具呢?因为它看不到包头。

你能够利用访问列表来查看特定的主机、协议、端口或者网络。 当然它不是真正意义上的协议分析工具,但是它是IOS集成的一个特性,比别的工具相对来说使用起来方便快捷。下面的例子是一个记录所有通过你的路由器的Telnet包的配置。
access-list 101 permit tcp any any eq telnet
debug ip packet detail 101
IP packet debugging is on (detailed) for access list 101

Listing E 总结了一些debug输出的示例。

你可以从输出结果看到获取的ip 源、目的(地址、端口号)接口、sequence 号、acknowledgement 号, window 尺寸, 和 TCP 通讯标志 (SYN, ACK, FIN)。

This post was written by:

不唠嗑

***CPU及内存的使用率在50%以上时,慎用debug命令***

附:Listing C
Listing C

Router#deb all

 

This may severely impact network performance. Continue? (yes/[no]): yes

All possible debugging has been turned on

Router#

Router#show debug

"debug 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 seconds

UDPtn debugging is off

LPD 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 on

AT/EIGRP:

  AT/EIGRP Event Logging debugging is off

AppleTalk 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 on

bind debbuging is on

ber debbuging is on

receivedata debbuging is on

request debbuging is on

referrals debbuging is on

error debbuging is on

 

DLSw:  

  DLSw Core debugging is off

  DLSw Reachability debugging is off

  DLSw Local Circuit debugging is off

DLSw reachability debugging is on at event level for all protocol traffic

DLSw core message debugging is on

DLSw core state debugging is on

DLSw core flow control debugging is on

DLSw core xid debugging is on

  DLSw Local Circuit debugging is on

SNA:

  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 on

NCIA: Debug server is on

NCIA: Debug circuit all is on

BSTUN:

  BSTUN event debugging is on

  BSTUN packet debugging is on

     BSTUN packet display size for debugging is 20

BSC:

  BSC event debugging is on

  BSC packet debugging is on

  BSC diagnostic debugging is on

     BSC packet display size for debugging is 20

ASPP:

  ASPP event debugging is on

  ASPP packet debugging is on

     ASPP packet display size for debugging is 20

MGCP:

  Media Gateway Control Protocol input packets in hex value debugging is off

Rudpv1: Application debugging is enabled

Rudpv1: Performance debugging is enabled

Rudpv1: Retransmit/softreset is enabled

Rudpv1: Segment debugging is enabled

Rudpv1: Signal debugging is enabled

Rudpv1: State debugging is enabled

Rudpv1: Timer debugging is enabled

Rudpv1: 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 off

Radius protocol debugging is off (detailed)

Voice Telephony session debugging is on

Voice Telephony dsp debugging is on

Voice Telephony error debugging is on

Voice Telephony stats debugging is on

Voice Telephony tone generation debugging is on

TSP call debugging is on

TSP port debugging is on

TSP error debugging is on

TSP ROSE ASN  debugging is on

CCH323 SPI: H225 State Machine tracing is enabled

CCH323 SPI: H245 State Machine tracing is enabled

CCH323 SPI: RAS State Machine tracing is enabled

CCH323 SPI: RTP packet tracing is enabled

CCH323 SPI: Session tracing is enabled

CCH323 SPI: CCH323 Error debug is enabled

CCH323 SPI: CCH323 Rawmsg debug is enabled

CCH323 SPI: CCH323 H450 debug is enabled

RTP SPI error tracing is enabled.

RTP SPI function in/out tracing is enabled.

RTP SPI Session tracing is enabled

Translation debug detail is on

Translation debug min is on

CCSIP SPI: SIP Call Statistics tracing is enabled

CCSIP SPI: SIP Call Message tracing is enabled

CCSIP SPI: SIP Call State Machine tracing is enabled

CCSIP SPI: SIP Call Events tracing is enabled

SIP : SIP error debug tracing is enabled

QoS Module : Function Trace Debugging is enabled

 

QoS Module : Events Debugging is enabled

 

Voice Port Module session debugging is on

Voice Port Module DSP message debugging is on

Voice Port Module error debugging is on

Voice Port Module signaling debugging is on

Voice Port Module voaal2 debugging is on

Voice Port Module trunk conditioning is on

FRF.11 Session tracing is enabled

Local MobileIP: aging arp mobility cacCCSWVOICE Session tracing is enabled

CCSWVOICE Vofr Session tracing is enabled

CCSWVOICE Vofr Error tracing is enabled

CCSWVOICE Voatm Session tracing is enabled

CCSWVOICE Voatm Error tracing is enabled`

settlement:

  error conditions tracing is on

  enter to functions tracing is on

  exit from functions tracing is on

  memory tracing is on

  transaction tracing is on

  network intput/output tracing is on

  security tracing is on

  miscellaneous tracing is on

  ssl interface tracing is on

DSPU:

  DSPU activation debugging is on for all PUs

  DSPU packet debugging is on for all PUs

  DSPU state change debugging is on for all PUs

  DSPU trace debugging is on for all PUs

  DSPU alert debugging is on for all PUs

 

ALPS:

  ALPS peer event debugging for all peers is on

  ALPS peer packet debugging for all peers is on

  ALPS circuit event debugging for all circuits is on

  ALPS ascu event debugging for all ascus is on

  ALPS ascu packet debugging for all ascus is on

  ALPS ascu detail debugging for all ascus is on

  ALPS ascu router packet format for all ascus is on

 Error debugging enabled for RTR responder

 Trace debugging enabled for RTR responder

 

Router#

Router#un all

All possible debugging has been turned off

Router#

阅读(2912) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~