Cisco IOS Show commands can tell you many things about what is going on with your router or switch, but they can’t tell you everything. For example, Show commands cannot tell you when routes drop in or out of the routing table, why an ISDN line failed to connect, whether a packet really went out the router, or what ICMP error code was received. On the other hand, Cisco IOS Debug commands can tell you all these things, and more.

Besides providing more detailed information than what Show commands can provide, Debug commands have the benefit of providing information in “real time” (or dynamically). This is contrary to Show commands that just take a snapshot in time and display the results on your console (somewhat static results). This real-time difference can be very helpful in diagnosing problems.

Let’s take a look at a simple example. We are going to view RIP (Routing Information Protocol) in Debug mode.

Router# debug ip RIP

RIP protocol debugging is on

To verify what debugging is enabled, use this command:

Router# show debug

  RIP protocol debugging is on

The output from whatever type of debug is enabled will be sent to wherever the Cisco IOS logging system tells that output to go. Either you will receive the output on your screen, it will go to the buffered log on the router, or it will go to a syslog server across the network (or all of these).

To see what level the various outputs are set to and where the output will go, type:

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#

The console should display RIP updates that are sent and received through the RIP protocol. Here is an example of what you might see for RIP debugging:

*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

Remember that you should use Debug only for a short time to get a snippet of information, and then turn Debug off as it can be a serious performance hit on your router.

 

DEBUG COmmands

 

debug ip drp

 

Use the debug ip drp EXEC command to display Director Response Protocol (DRP) information. The no form of this command disables debugging output.

 

[no] debug ip drp

 

Usage Guidelines

 

The debug ip drp command is used to debug the director response agent used by the Distributed Director product. The Distributed Director can be used to dynamically respond to Domain Name System (DNS) queries with the IP address of the "best" host based on various criteria.

 

Sample Display

 

shows sample debug ip drp output. This example shows the packet origination, the IP address that information is routed to, and the route metrics that were returned.

 

Figure 2-92 Sample Debug IP DRP Output

 

Router# debug ip drp

 

DRP: received v1 packet from 172.31.232.8, via Ethernet0

 

DRP: RTQUERY for 172.31.58.94 returned internal=0, external=0

 

describes the fields shown in .

 

 

 

 

debug ip dvmrp

 

Use the debug ip dvmrp EXEC command to display information on Distance Vector Multiprotocol Routing Protocol (DVMRP) packets received and transmitted. The no form of this command disables debugging output.

 

[no] debug ip dvmrp [detail [access-list] [in | out]]

 

Syntax Description

 

 

Usage Guidelines

 

Use the debug ip dvmrp detail command with care. This command generates a great deal of output and can interrupt other activity on the router when it is invoked.

 

Sample Displays

 

shows sample debug ip dvmrp output.

 

Figure 2-93 Sample Debug IP DVMRP Output

 

Router# debug ip dvmrp

 

DVMRP: Received Report on Ethernet0 from 172.19.244.10

 

DVMRP: Received Report on Ethernet0 from 172.19.244.11

 

DVMRP: Building Report for Ethernet0 224.0.0.4

 

DVMRP: Send Report on Ethernet0 to 224.0.0.4

 

DVMRP: Sending IGMP Reports for known groups on Ethernet0

 

DVMRP: Received Report on Ethernet0 from 172.19.244.10

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Building Report for Tunnel0 224.0.0.4

 

DVMRP: Send Report on Tunnel0 to 192.168.199.254

 

DVMRP: Send Report on Tunnel0 to 192.168.199.254

 

DVMRP: Send Report on Tunnel0 to 192.168.199.254

 

DVMRP: Send Report on Tunnel0 to 192.168.199.254

 

DVMRP: Radix tree walk suspension

 

DVMRP: Send Report on Tunnel0 to 192.168.199.254

 

Explanations for individual lines of output from follow.

 

The following lines show that the router received DVMRP routing information and placed it in the mroute table:

 

DVMRP: Received Report on Ethernet0 from 172.19.244.10

 

DVMRP: Received Report on Ethernet0 from 172.19.244.11

 

The following lines show that the router is creating a report to send to another DVMRP router:

 

DVMRP: Building Report for Ethernet0 224.0.0.4

 

DVMRP: Send Report on Ethernet0 to 224.0.0.4

 

provides a list of internet multicast addresses supported for host IP implementations.

 

 

 

 

The following lines show that a protocol update report has been sent to all known multicast groups. Hosts use IGMP reports to communicate with routers and to request to join a multicast group. In this case, the router is sending an IGMP report for every known group to the host, which is running mrouted. The host the responds as though the router was a host on the LAN segment that wants to receive multicast packets for the group.

 

DVMRP: Sending IGMP Reports for known groups on Ethernet0

 

shows sample debug ip dvmrp detail output.

 

Figure 2-94 Sample Debug IP DVMRP Detail Output

 

Router# debug ip dvmrp detail 

 

DVMRP: Sending IGMP Reports for known groups on Ethernet0

 

DVMRP: Advertise group 224.2.224.2 on Ethernet0

 

DVMRP: Advertise group 224.2.193.34 on Ethernet0

 

DVMRP: Advertise group 224.2.231.6 on Ethernet0

 

DVMRP: Received Report on Tunnel0 from 192.168.199.254

 

DVMRP: Origin 150.166.53.0/24, metric 13, distance 0

 

DVMRP: Origin 150.166.54.0/24, metric 13, distance 0

 

DVMRP: Origin 150.166.55.0/24, metric 13, distance 0

 

DVMRP: Origin 150.166.56.0/24, metric 13, distance 0

 

DVMRP: Origin 150.166.92.0/24, metric 12, distance 0

 

DVMRP: Origin 150.166.100.0/24, metric 12, distance 0

 

DVMRP: Origin 150.166.101.0/24, metric 12, distance 0

 

DVMRP: Origin 150.166.142.0/24, metric 8, distance 0

 

DVMRP: Origin 150.166.200.0/24, metric 12, distance 0

 

DVMRP: Origin 150.166.237.0/24, metric 12, distance 0

 

DVMRP: Origin 150.203.5.0/24, metric 8, distance 0

 

Explanations for individual lines of output from follow.

 

The following lines show that this group is available to the DVMRP router. The mrouted process on the host will forward the source and multicast information for this group through the DVMRP cloud to other members.

 

DVMRP: Advertise group 224.2.224.2 on Ethernet0

 

The following lines show the DVMRP route information:

 

DVMRP: Origin 150.166.53.0/24, metric 13, distance 0

 

DVMRP: Origin 150.166.54.0/24, metric 13, distance 0

 

The metric is the number of hops the route has covered, and the distance is the administrative distance.

 

debug ip eigrp

 

Use the debug ip eigrp EXEC command to display information on Enhanced IGRP protocol packets. The no form of this command disables debugging output.

 

[no] debug ip eigrp

 

Usage Guidelines

 

This command helps you analyze the packets that are sent and received on an interface. Because the debug ip eigrp command generates large amounts of output, only use it when traffic on the network is light.

 

Sample Display

 

shows sample debug ip eigrp output.

 

Figure 2-95 Sample Debug IP EIGRP Output

 

Router# debug ip eigrp

 

IP-EIGRP: Processing incoming UPDATE packet

 

IP-EIGRP: Ext 192.168.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000 104960

 

IP-EIGRP: Ext 192.168.0.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000 104960

 

IP-EIGRP: Ext 192.168.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000 104960

 

IP-EIGRP: 172.24.43.0 255.255.255.0, - do advertise out Ethernet0/1

 

IP-EIGRP: Ext 172.24.43.0 255.255.255.0 metric 371200 - 256000 115200

 

IP-EIGRP: 192.135.246.0 255.255.255.0, - do advertise out Ethernet0/1

 

IP-EIGRP: Ext 192.135.246.0 255.255.255.0 metric 46310656 - 45714176 596480

 

IP-EIGRP: 172.24.40.0 255.255.255.0, - do advertise out Ethernet0/1

 

IP-EIGRP: Ext 172.24.40.0 255.255.255.0 metric 2272256 - 1657856 614400

 

IP-EIGRP: 192.135.245.0 255.255.255.0, - do advertise out Ethernet0/1

 

IP-EIGRP: Ext 192.135.245.0 255.255.255.0 metric 40622080 - 40000000 622080

 

IP-EIGRP: 192.135.244.0 255.255.255.0, - do advertise out Ethernet0/1

 

describes significant fields in the debug messages shown in .

 

 

 

 

debug ip ftp

 

To activate the debugging option to track the transactions submitted during an FTP session, use the debug ip ftp privileged EXEC command. To disable debugging output, use the no form of this command.

 

[no] debug ip ftp

 

Usage Guidelines

 

The debug ip ftp command is useful for debugging problems associated with File Transfer Protocol (FTP).

 

Sample Display

 

The following is an example of the debug ip ftp command:

 

Router# debug ip ftp

 

FTP transactions debugging is on

 

The following is sample output from the debug ip ftp command:

 

FTP: 220 ProFTPD 1.2.0pre8 Server (DFW Nostrum FTP Server) [defiant.dfw.nostrum.com]

 

Dec 27 22:12:09.133: FTP: ---> USER router

 

Dec 27 22:12:09.133: FTP: 331 Password required for router.

 

Dec 27 22:12:09.137: FTP: ---> PASS WQHK5JY2

 

Dec 27 22:12:09.153: FTP: 230 Anonymous access granted, restrictions apply.

 

Dec 27 22:12:09.153: FTP: ---> TYPE I

 

Dec 27 22:12:09.157: FTP: 200 Type set to I.

 

Dec 27 22:12:09.157: FTP: ---> PASV

 

.......

 

.......

 

Dec 27 22:12:09.173: FTP: ---> QUIT

 

Dec 27 22:12:09.181: FTP: 221 Goodbye.

 

DRP: RTQUERY for 172.31.58.94 returned internal=0, external=0

 

debug ip https authentication

 

Use the debug ip https authentication privileged EXEC command to troubleshoot HTTP authentication problems. This command displays the authentication method the router attempted and authentication-specific status messages. The no form of this command disables debugging output.

 

[no] debug ip https authentication

 

Sample Display

 

shows sample debug ip https authentication output.

 

Figure 2-96 Sample Debug IP HTTP Authentication Output

 

Router# debug ip https authentication

 

Authentication for url `/' `/' level 15 privless `/'

 

Authentication username = `local15' priv-level = 15 auth-type = local

 

describes the output fields created by the debug ip https authentication command.

 

Table 2-52 Debug IP HTTP Authentication Descriptions

 

 

debug ip https ezsetup

 

Use the debug ip https ezsetup EXEC command to display the configuration changes that occur during the EZ Setup process. The no form of this command disables debugging output.

 

[no] debug ip https ezsetup

 

Usage Guidelines

 

Use the debug ip https ezsetup command to verify the EZ Setup actions without changing the router's configuration.

 

EZ Setup is a form you fill out to perform basic router configuration from most Hypertext Markup Language (HTML) browsers.

 

Sample Display

 

shows sample debug ip https ezsetup output. This example shows the configuration changes for the router when the EZ Setup form has been submitted.

 

Figure 2-97 Sample Debug IP HTTP EZ Setup Output

 

Router# debug ip https ezsetup

 

service timestamps debug

 

service timestamps log

 

service password-encryption

 

!

 

hostname router-name

 

!

 

enable secret router-pw

 

line vty 0 4

 

password router-pw

 

!

 

interface ethernet 0

 

 ip address 172.21.52.9 255.255.255.0

 

 no shutdown

 

 ip helper-address 172.31.2.132

 

ip name-server 172.31.2.132

 

isdn switch-type basic-5ess

 

username Remote-name password Remote-chap

 

interface bri 0

 

 ip unnumbered ethernet 0

 

 encapsulation ppp

 

 no shutdown

 

 dialer map ip 192.168.254.254 speed 56 name Remote-name Remote-number

 

 isdn spid1 spid1

 

 isdn spid2 spid2

 

 ppp authentication chap callin

 

 dialer-group 1

 

!

 

ip classless

 

access-list 101 deny udp any any eq snmp

 

access-list 101 deny udp any any eq ntp

 

access-list 101 permit ip any any

 

dialer-list 1 list 101

 

ip route 0.0.0.0 0.0.0.0 192.168.254.254

 

ip route 192.168.254.254 255.255.255.255 bri 0

 

logging buffered

 

snmp-server community public RO

 

ip https server

 

ip classless

 

ip subnet-zero

 

!

 

end

 

Related Commands

 

debug ip https token
debug ip https transaction
debug ip https url

 

debug ip https ssi

 

Use the debug ip https ssi EXEC command to display information about the HTML SSI EXEC command or HTML SSI ECHO command. The no form of this command disables debugging output.

 

[no] debug ip https ssi

 

Sample Display

 

shows sample debug ip https ssi command output.

 

Figure 2-98 Sample Debug IP HTTP SSI Output

 

Router# debug ip https ssi

 

HTML: filtered command `exec cmd="show users"'

 

HTML: SSI command `exec'

 

HTML: SSI tag `cmd' = "show users"

 

HTML: Executing CLI `show users' in mode `exec' done

 

Explanations for individual lines of output from follow.

 

The following line shows the contents of the Server Side Include (SSI) EXEC command:

 

HTML: filtered command `exec cmd="show users"'

 

The following line indicates the type of SSI command that was requested:

 

HTML: SSI command `exec'

 

The following line shows the argument "show users" assigned to the tag `cmd':

 

HTML: SSI tag 'cmd' = "show users"

 

The following line indicates that the Cisco IOS show users command is being executed in EXEC mode:

 

HTML: Executing CLI `show users' in mode `exec' done

 

debug ip https token

 

Use the debug ip https token EXEC command to display individual tokens parsed by the Hypertext Transfer Protocol (HTTP) server. The no form of this command disables debugging output.

 

[no] debug ip https token

 

Usage Guidelines

 

Use the debug ip https token command to display what the HTTP server is parsing at a low level. To display what the HTTP server is parsing at a high level, use the debug ip https transaction command.

 

Sample Display

 

shows a partial sample of debug ip https token output. In this example, the browser accessed the router's home page https://router-name/. The output gives the token parsed by the HTTP server and its length.

 

Figure 2-99 Sample Debug IP HTTP Token Output

 

Router# debug ip https token

 

HTTP: token len 3: 'GET'

 

HTTP: token len 1: ' '

 

HTTP: token len 1: '/'

 

HTTP: token len 1: ' '

 

HTTP: token len 4: 'HTTP'

 

HTTP: token len 1: '/'

 

HTTP: token len 1: '1'

 

HTTP: token len 1: '.'

 

HTTP: token len 1: '0'

 

HTTP: token len 2: '\15\12'

 

HTTP: token len 7: 'Referer'

 

HTTP: token len 1: ':'

 

HTTP: token len 1: ' '

 

HTTP: token len 4: 'https'

 

HTTP: token len 1: ':'

 

HTTP: token len 1: '/'

 

HTTP: token len 1: '/'

 

HTTP: token len 3: 'www'

 

HTTP: token len 1: '.'

 

HTTP: token len 3: 'foo'

 

HTTP: token len 1: '.'

 

HTTP: token len 3: 'com'

 

HTTP: token len 1: '/'

 

HTTP: token len 2: '\15\12'

 

HTTP: token len 10: 'Connection'

 

HTTP: token len 1: ':'

 

HTTP: token len 1: ' '

 

HTTP: token len 4: 'Keep'

 

HTTP: token len 1: '-'

 

HTTP: token len 5: 'Alive'

 

HTTP: token len 2: '\15\12'

 

HTTP: token len 4: 'User'

 

HTTP: token len 1: '-'

 

HTTP: token len 5: 'Agent'

 

HTTP: token len 1: ':'

 

HTTP: token len 1: ' '

 

HTTP: token len 7: 'Mozilla'

 

HTTP: token len 1: '/'

 

HTTP: token len 1: '2'

 

HTTP: token len 1: '.'

 

...

 

Related Commands

 

debug ip https ezsetup
debug ip https transaction
debug ip https url

 

debug ip https transaction

 

Use the debug ip https transaction EXEC command to display Hypertext Transfer Protocol (HTTP) server transaction processing. The no form of this command disables debugging output.

 

[no] debug ip https transaction

 

Usage Guidelines

 

Use the debug ip https transaction command to display what the HTTP server is parsing at a high level. To display what the HTTP server is parsing at a low level, use the debug ip https token command.

 

Sample Display

 

shows sample debug ip https transaction output. In this example, the browser accessed the router's home page https://router-name/.

 

Figure 2-100 Sample Debug IP HTTP Transaction Output

 

Router# debug ip https transaction

 

HTTP: parsed uri '/'

 

HTTP: client version 1.0

 

HTTP: parsed extension Referer

 

HTTP: parsed line https://www.foo.com/

 

HTTP: parsed extension Connection

 

HTTP: parsed line Keep-Alive

 

HTTP: parsed extension User-Agent

 

HTTP: parsed line Mozilla/2.01 (X11; I; FreeBSD 2.1.0-RELEASE i386)

 

HTTP: parsed extension Host

 

HTTP: parsed line router-name

 

HTTP: parsed extension Accept

 

HTTP: parsed line image/gif, image/x-xbitmap, image/jpeg, image/

 

HTTP: parsed extension Authorization

 

HTTP: parsed authorization type Basic

 

HTTP: received GET ''

 

lists describes some of the fields in .

 

 

 

 

Related Commands

 

debug ip https ezsetup
debug ip https token
debug ip https url

 

debug ip https url

 

Use the debug ip https url EXEC command to show the uniform resource locators (URLs) accessed from the router. The no form of this command disables debugging output.

 

[no] debug ip https url

 

Usage Guidelines

 

Use the debug ip https url command to keep track of the URLs that are accessed and to determine from which hosts the URLs are accessed.

 

Sample Display

 

shows a partial sample of debug ip https url output. In this example, the HTTP server accessed the URLs / and /exec. The output shows the URL being requested and the IP address of the host requesting the URL.

 

Figure 2-101 Sample Debug IP HTTP URL Output

 

Router# debug ip https url 

 

HTTP: processing URL '/' from host 172.31.2.141

 

HTTP: processing URL '/exec' from host 172.31.2.141

 

Related Commands

 

debug ip https ezsetup
debug ip https token
debug ip https transaction

 

debug ip icmp

 

Use the debug ip icmp EXEC command to display information on Internal Control Message Protocol (ICMP) transactions. The no form of this command disables debugging output.

 

[no] debug ip icmp

 

Usage Guidelines

 

This command helps you determine whether the router is sending or receiving ICMP messages. Use it, for example, when you are troubleshooting an end-to-end connection problem.

 

Sample Display

 

shows sample debug ip icmp output.

 

Figure 2-102 Sample Debug IP ICMP Output

 

Router# debug ip icmp

 

ICMP: rcvd type 3, code 1, from 10.95.192.4

 

ICMP: src 10.56.0.202, dst 172.16.16.1, echo reply

 

ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15

 

ICMP: src 172.16.12.35, dst 172.16.20.7, echo reply

 

ICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21

 

ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15

 

ICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21

 

ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15

 

ICMP: src 10.56.0.202, dst 172.16.16.1, echo reply

 

ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15

 

ICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21

 

ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15

 

describes significant fields in the first line of debug ip icmp output shown in .

 

 

 

 

describes significant fields in the second line of debug ip icmp output in .

 

 

 

 

Other messages that the debug ip icmp command can generate follow.

 

When an IP router or host sends out an ICMP mask request, the following message is generated when the router sends a mask reply:

 

ICMP: sending mask reply (255.255.255.0) to 172.21.80.23 via Ethernet0

 

The following two lines are examples of the two forms of this message. The first form is generated when a mask reply comes in after the router sends out a mask request. The second form occurs when the router receives a mask reply with a nonmatching sequence and ID. See Appendix I of RFC 950, "Internet Standard Subnetting Procedures," for details.

 

ICMP: mask reply 255.255.255.0 from 172.21.80.31

 

ICMP: unexpected mask reply 255.255.255.0 from 172.21.80.32

 

The following output indicates that the router sent a redirect packet to the host at address 172.21.80.31, instructing that host to use the gateway at address 172.21.80.23 in order to reach the host at destination address 172.16.1.111:

 

ICMP: redirect sent to 172.21.80.31 for dest 172.16.1.111 use gw 172.21.80.23

 

The following message indicates that the router received a redirect packet from the host at address 172.21.80.23, instructing the router to use the gateway at address 172.21.80.28 in order to reach the host at destination address 172.21.81.34:

 

ICMP: redirect rcvd from 172.21.80.23 -- for 172.21.81.34 use gw 172.21.80.28

 

The following message is displayed when the router sends an ICMP packet to the source address (172.21.94.31 in this case), indicating that the destination address (172.16.13.33 in this case) is unreachable:

 

ICMP: dst (172.16.13.33) host unreachable sent to 172.21.94.31

 

The following message is displayed when the router receives an ICMP packet from an intermediate address (172.21.98.32 in this case), indicating that the destination address (172.16.13.33 in this case) is unreachable:

 

ICMP: dst (172.16.13.33) host unreachable rcv from 172.21.98.32

 

Depending on the code received (as describes), any of the unreachable messages can have any of the following "strings" instead of the "host" string in the message:

 

net

 

protocol

 

port

 

frag. needed and DF set

 

source route failed

 

prohibited

 

The following message is displayed when the TTL in the IP header reaches zero and a time exceed ICMP message is sent. The fields are self-explanatory.

 

ICMP: time exceeded (time to live) send to 10.95.1.4 (dest was 172.16.1.111)

 

The following message is generated when parameters in the IP header are corrupted in some way and the parameter problem ICMP message is sent. The fields are self-explanatory.

 

ICMP: parameter problem sent to 128.121.1.50 (dest was 172.16.1.111)

 

Based on the preceding information, the remaining output can be easily understood.

 

ICMP: parameter problem rcvd 172.21.80.32

 

ICMP: source quench rcvd 172.21.80.32

 

ICMP: source quench sent to 128.121.1.50 (dest was 172.16.1.111)

 

ICMP: sending time stamp reply to 172.21.80.45

 

ICMP: sending info reply to 172.21.80.12

 

ICMP: rdp advert rcvd type 9, code 0, from 172.21.80.23

 

ICMP: rdp solicit rcvd type 10, code 0, from 172.21.80.43

 

debug ip igmp

 

Use the debug ip igmp EXEC command to display Internet Group Management Protocol (IGMP) packets received and transmitted, as well as IGMP-host related events. The no form of this command disables debugging output.

 

[no] debug ip igmp

 

Usage Guidelines

 

This command helps discover whether the IGMP processes are functioning. In general, if IGMP is not working, the router process never discovers that there is another host on the network that is configured to receive multicast packets. In dense mode this means the packets will be delivered intermittently (a few every 3 minutes). In sparse mode they will never be delivered.

 

Use this command in conjunction with debug ip pim and debug ip mrouting to observe additional multicast activity and to see what is happening to the multicast routing process, or why packets are forwarded out of particular interfaces.

 

Sample Display

 

shows sample debug ip igmp output.

 

Figure 2-103 Sample Debug IP IGMP Output

 

Router# debug ip igmp