Debug Command Reference

This chapter covers the debug commands that you can use to diagnose and resolve internetworking problems. This chapter includes two sections:

• General debugging information

• Debug command listing

Caution Because debugging output is assigned high priority, excessive debugging output can render the system unusable. For this reason, you should only use debug commands to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during off hours, when lower network traffic and fewer users reduce the risk of using them.

General Debugging Information

This section covers the following topics:

• Using debug commands

• Using the debug ? command

• Using the debug all command

• Generating debugging output

• Redirecting debugging output

Using Debug Commands

You can use the privileged EXEC command debug to display several classes of network events on the console terminal.

Most debug commands do not take any required or optional arguments. For example, to enable the debug broadcast command, enter the following in privileged mode at the command line:

To turn off the debug broadcast command, enter the following in privileged mode at the command line:

To display the state of each debugging option, enter the following at the command line:

Using the Debug ? Command

To list and briefly describe all of the debugging command options, enter the debug ? command in privileged mode at the command line.

Using the Debug All Command

To enable all system diagnostics, enter the following in privileged mode at the command line:

Its converse, the undebug all command, turns off all diagnostic output. The undebug all command is a convenient way to ensure that you have not accidentally left any debug commands turned on.

Caution Because debugging output takes priority over other network traffic, and because the debug all command generates more output than any other debug command, it can severely diminish the router's performance or even render it unusable. In virtually all cases, it is best to use more specific debug commands.

Generating Debugging Command Output

Turning on a debugging command can result in output similar to the example for the debug broadcast command shown in Figure 10-1.

Redirecting Debugging and Error Message Output

By default, the network server sends the output from debug commands and system error messages to the console terminal. If you accept this default, it is best to monitor debugging output using a VTY connection, rather than the console port.

To redirect debugging output, use the logging command options within configuration mode.

Possible destinations include the console terminal, virtual terminals, and UNIX hosts running a syslog server; the syslog format is compatible with 4.3 BSD UNIX and its derivatives.

To configure message logging, you need to be in the configuration command collection mode. To enter this mode, use the EXEC command configure terminal at the EXEC prompt. The following sections describe how to implement these redirection options.

Enabling Message Logging

To enable message logging to all supported destinations other than the console, enter the following:

This behavior is the default.

To enable logging to the console terminal only, enter the following:

Logging Messages to the Console

To limit the types of messages that are logged to the console, use the logging console global configuration command. The full syntax of this command follows.

The logging console command limits the logging messages displayed on the console terminal to messages with a level number at or below the specified severity level, which is specified by the level argument.

The argument level can be one of the keywords listed in Table 10-1. They are listed in order from the most severe to the least severe level.

Example

This command sets console logging of messages at the debugging level:

!
logging console debugging
!

Logging Messages to an Internal Buffer

The default logging device is the console; all messages are displayed on the console unless otherwise specified.

To log messages to an internal buffer, use the logging buffered global configuration command. The full command syntax follows.

The logging buffered command copies logging messages to an internal buffer instead of writing them to the console terminal. The buffer is circular in nature, so newer messages overwrite older messages. To display the messages that are logged in the buffer, use the EXEC command show logging. The first message displayed is the oldest message in the buffer.

The no logging buffered command cancels the use of the buffer and writes messages to the console terminal (the default).

Logging Messages to Another Monitor

To limit the level of messages logged to the terminal lines (monitors), use the logging monitor global configuration command. The full syntax of this command follows.

The logging monitor command limits the logging messages displayed on terminal lines other than the console line to messages with a level at or above the value of the level variable. The argument level is one of the keywords described for the logging console command in a previous section, "Logging Messages to the Console." To display logging messages on a terminal, use the privileged EXEC command terminal monitor.

The no logging monitor command disables logging to terminal lines other than the console line.

This command sets the level of messages displayed on monitors other than the console to notification:

!
logging monitor notification
!

Logging Messages to a UNIX Syslog Server

To log messages to the syslog server host, use the logging global configuration command. The full syntax is as follows:

The logging command identifies a syslog server host to receive logging messages. The argument internet-address is the Internet address of the host. By issuing this command more than once, you build a list of syslog servers that receive logging messages.

The no logging command deletes the syslog server with the specified address from the list of syslogs.

Limiting Messages to a Syslog Server

To limit how many messages are sent to the syslog servers, use the logging trap global configuration command. Its full syntax follows.

The logging trap command limits the logging messages sent to syslog servers to messages with a level at or above the value of the level variable. The argument level is one of the keywords described for the logging console command in Table 10-1.

To send logging messages to a syslog server, specify its host address with the logging command.

The default trap level is informational.

The no logging trap command disables logging to syslog servers.

The current software generates four categories of syslog messages:

• Error messages about software or hardware malfunctions, displayed at the errors level.

• Interface up/down transitions and system restart messages, displayed at the notification level.

• Reload requests and low-process stack messages, displayed at the informational level.

• Output from the debug commands, displayed at the debugging level.

The EXEC command show logging displays the addresses and levels associated with the current logging setup. The command output also includes ancillary statistics.

Example

To set up the syslog daemon on a 4.3 BSD UNIX system, include a line such as the following in the file /etc/syslog.conf:

local7.debug /usr/adm/logs/tiplog

The local7 keyword specifies the logging facility to be used.

The debug argument specifies the syslog level. See the previous level arguments list for other arguments that can be listed.

The UNIX system sends messages at or below this level to the file specified in the next field. The file must already exist, and the syslog daemon must have permission to write to it.

Debug Command Listing

This section includes an alphabetical listing of debug commands. Documentation for each command includes a description of its use, example output, and a description of that output.

Output formats of the various debug commands vary. Some generate a single line of output per packet, whereas others generate multiple lines of output per packet. Some generate a great deal of output, whereas others generate occasional output. Some generate lines of text; others generate information in field format. Thus, the way the debug commands are documented also varies. For example, for debug commands that generate lines of text, the output is described line-by-line. For debug commands that generate output in field format, tables are used to describe the fields.

Debug Apple-ARP

Use the debug apple-arp command to enable debugging of the AppleTalk address resolution protocol.

This command is helpful when you experience problems communicating with a node on the network you control (neighbor). If the debug apple-arp display indicates that the router is receiving AARP probes, you can assume that the problem does not reside at the physical layer.

Figure 10-2 shows example debug apple-arp output.

Explanations for representative lines of output in Figure 10-2 follow.

The following line of output indicates that the router has requested the hardware MAC address of the host at network address 4160.26.

Ether0: AARP: Sent resolve for 4160.26

The following line of output indicates that the host at network address 4160.26 has replied, giving its MAC address (0000.0c00.0453). For completeness, the message also shows the network address to which the reply was sent and its hardware MAC address (also in parentheses).

Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9)

The following line of output indicates that the MAC address request is complete.

Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453)

Debug Apple-Errors

Use the debug apple-errors command to display errors occurring in the AppleTalk network.

To solve encapsulation problems, enable debug apple-errors and debug apple-packet together.

Figure 10-3 shows example debug apple-errors output when a router is brought up with a zone that does not agree with the zone list of other routers on the network.

As Figure 10-3 suggests, a single error message indicates zone list incompatibility; this message is sent out periodically until the condition is corrected or debug apple-errors is turned off.

Most of the other messages that debug apple-errors can generate are quite obscure or indicate a very serious problem with the AppleTalk network. Some of these other messages follow.

In the following message, RTMPRsp, RTMPReq, ATP, AEP, ZIP, ADSP, or SNMP could replace NBP, and llap dest not for us could replace wrong encapsulation.

Packet discarded, src 4160.12-254,dst 4160.19-254,NBP,wrong encapsulation

In the following message, besides invalid echo packet, other possible errors are: unsolicited AEP echo reply, unknown echo function, invalid ping packet, unknown ping function, and bad responder packet type.

Ethernet0: AppleTalk packet error; no source address available
AT: pak_reply: dubious reply creation, dst 4160.19
AT: Unable to get a buffer for reply to 4160.19
Processing error, src 4160.12-254,dst 4160.19-254,AEP, invalid echo packet

The debug apple-errors command can print out other messages when other debugging commands are also turned on. When both debug apple-errors and debug apple-events are turned on, the following message can be generated:

Proc err, src 4160.12-254,dst 4160.19-254,ZIP,NetInfo Reply format is invalid

In the previous message, besides NetInfo Reply format is invalid, other possible errors are: NetInfoReply not for me, NetInfoReply ignored, NetInfoReply for operational net ignored, NetInfoReply from invalid port, unexpected NetInfoReply ignored, cannot establish primary zone, no primary has been set up, primary zone invalid, net information mismatch, multicast mismatch, and zones disagree.

When both debug apple-errors and debug apple-nbp are turned on, the following message can be generated:

Processing error, ...,NBP,NBP name invalid

In the previous message, besides NBP name invalid, other possible errors are: NBP type invalid, NBP zone invalid, not operational, error handling brrq, error handling proxy, NBP fwdreq unexpected, No route to srcnet, Proxy to "*" zone, Zone "*" from extended net, No zone info for "*", and NBP zone unknown.

When both debug apple-errors and debug apple-routing are turned on, the following message can be generated:

Processing error, ...,RTMPReq, unknown RTMP request

In the previous message, besides unknown RTMP request, other possible errors are: RTMP packet header bad, RTMP cable mismatch, routed RTMP data, RTMP bad tuple, and Not Req or Rsp.

Debug Apple-Events

Use the debug apple-events command to display debugging information about AppleTalk special events, neighbors becoming reachable/unreachable, and interfaces going up/down. Only significant events (for example, neighbor and/or route changes) are logged.

The debug apple-events command is very useful for solving AppleTalk network problems, because it provides an overall picture of the stability of the network. In a stable network, the debug apple-events command does not return any information. If, however, the command generates numerous messages, these messages can indicate where the problem might lie.

When configuring or making changes to a router or interface for AppleTalk, enable debug apple-events. This will alert you to the progress of the changes or to any errors that might result. You should also use this command periodically when you suspect network problems.

The debug apple-events command is also useful to determine whether network flapping is occuring. If flapping (nodes toggling on- and off-line) is excessive, look for routers that only support 254 networks.

When you enable debug apple-events, you also will see any messages that the configuration command apple event-logging normally displays. Turning on debug apple-events, however, will not cause apple event-logging to be maintained in nonvolatile memory. Only turning on apple event-logging explicitly will store it in nonvolatile memory. Furthermore, if apple event-logging is already enabled, turning on or off debug apple-events will not affect apple event-logging.

Figure 10-4 shows example debug apple-events output that describes a nonseed router coming up in discovery mode.

As Figure 10-4 shows, the debug apple-events command can be very useful in tracking the discovery mode state changes through which an interface progresses. When no problems are encountered, the state changes progress as follows:

Line dow

Restarting

Probing (for its own address (node ID) using AARP)

Acquiring (sending out GetNetInfo requests)

Requesting zones (the list of zones for its cable)

Verifying (that the router's configuration is correct. If not, a port configuration mismatch is declared.)

Checking zones (to make sure its list of zones is correct)

Operational (participating in routing)

Explanations for individual lines of output in Figure 10-4 follow.

The following message indicates that a port is set. In this case, the zone multicast address is being reset.

Ether0: AT: Resetting interface address filters

The following messages indicate that the router is changing to restarting mode.

%AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restarted
Ether0: AppleTalk state changed; unknown -> restarting

The following message indicates that the router is probing in the startup range of network numbers (65280-65534) to discover its network number.

Ether0: AppleTalk state changed; restarting -> probing

The following message indicates that the router is enabled as a nonrouting node using a provisional network number within its startup range of network numbers. This type of message only appears if the network address the router will use differs from its configured address. This is always the case for a nonseed router; it is rarely the case for a seed router.

%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148

The following messages indicate that the router is sending out GetNetInfo requests to discover the default zone name and the actual network number range in which its network number should be chosen.

Ether0: AppleTalk state changed; probing -> acquiring
%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration

Now that the router has acquired the cable configuration information, the following message indicates that it restarts using that information.

Ether0: AppleTalk state changed; acquiring -> restarting

The following messages indicate that the router is probing for its actual network address.

Ether0: AppleTalk state changed; restarting -> line down
Ether0: AppleTalk state changed; line down -> restarting
Ether0: AppleTalk state changed; restarting -> probing

The following message indicates that the router has found an actual network address to use.

%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 4160.148

The following messages indicate that the router is sending out GetNetInfo requests to verify the default zone name and the actual network number range from which its network number should be chosen.

Ether0: AppleTalk state changed; probing -> acquiring
%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration

The following message indicates that the router is requesting the list of zones for its cable.

Ether0: AppleTalk state changed; acquiring -> requesting zones

The following messages indicate that the router is sending out GetNetInfo requests to make sure its understanding of the configuration is correct.

Ether0: AppleTalk state changed; requesting zones -> verifying
AT: Sent GetNetInfo request broadcast on Ethernet0

The following message indicates that the router is rechecking its list of zones for its cable.

Ethernet0: AppleTalk state changed; verifying -> checking zones

The following message indicates that the router is now fully operational as a routing node and can begin routing.

Ethernet0: AppleTalk state changed; checking zones -> operational

Figure 10-5 shows example debug apple-events output that describes a seed router coming up when no other router is on the wire.

As Figure 10-5 shows, a seed router can come up when no other router is on the wire; however, it must assume that its configuration (if accurate syntactically) is correct, because no other router can verify it. Notice that the last line in Figure 10-5 indicates this situation.

Figure 10-6 shows example debug apple-events output that describes a nonseed router coming up when there is no seed router on the wire.

As Figure 10-6 shows, when you attempt to bring up a nonseed router without a seed router on the wire, it never becomes operational; instead, it hangs in the acquiring mode and continues to send out periodic GetNetInfo requests.

Figure 10-7 shows example debug apple-events output when a seed router is brought up on an AppleTalk internet that is in compatibility mode (set up to accommodate extended as well as nonextended AppleTalk) and the router has violated internet compatibility.

The three configuration command lines that follow indicate the part of the router's configuration that caused the configuration mismatch shown in Figure 10-7.

lestat(config)#int e 0
lestat(config-if)#apple cab 41-41
lestat(config-if)#apple zone Marketign

The router shown in Figure 10-7 had been configured with a cable range of 41-41 instead of 40-40, which would have been accurate. To make matters worse, the zone name was configured incorrectly; the zone name should have been Marketing, rather than being mispelled as Marketign.

Debug Apple-NBP

Use the debug apple-nbp command to enable debugging output from the Name Binding Protocol (NBP) routines. To determine whether the router is receiving NBP lookups from a node on the AppleTalk network, enable debug apple-nbp at each node between the router and this node in order to determine where the problem lies.

Figure 10-8 shows example debug apple-nbp output.

The first three lines in Figure 10-8 describe an NBP lookup request.

AT: NBP ctrl = LkUp, ntuples = 1, id = 77
AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW Lab
AT: LkUp =:ciscoRouter@Low End SW Lab

Table 10-2 describes the fields in the first line of output in Figure 10-8.

Table 10-3 describes the fields in the second line of output in Figure 10-8.

The third line in Figure 10-8 essentially reiterates the information in the two lines above it, indicating that a Lookup request has been made regarding name-address pairs for all objects of the ciscoRouter type in the Low End SW Lab zone.

Since the router is defined as an object of type ciscoRouter in zone Low End SW Lab, the router sends an NBP lookup reply in response to this NBP lookup request. The following two lines of output from Figure 10-8 show the router's response.

AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77
AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW Lab

In the first line, ctrl = LkUp-Reply identifies this NBP packet as an NBP lookup request. The same value in the id field (id = 77) associates this lookup reply with the previous lookup request. The second line indicates that the network address associated with the router's entity name (lestat.Ether0:ciscoRouter@Low End SW Lab) is 4160.154. The fact that no other entity name/network address is listed indicates that the responder only knows about itself as an object of type ciscoRouter in zone Low End SW Lab.

Debug Apple-Packet

Use the debug apple-packet command to enable per-packet debugging output. It reports information on line when a packet is received or a transmit is attempted. The command allows you to monitor the types of packets being slow switched. It is roughly equivalent to turning on all the other AppleTalk debugging information. There will be at least one line of debugging output per AppleTalk packet processed.

When invoked in conjunction with the commands debug apple-routing, debug apple-zip, and debug apple-nbp, the debug apple-packet command adds protocol processing information in addition to generic packet details. It reports protocol processing and successful completion or failure information.

When invoked in conjunction with the command debug apple-errors, the debug apple-packet command reports packet-level problems, such as those concerning encapsulation, for example.

Figure 10-9 shows example debug apple-packet output.

Table 10-4 describes the fields in the first line of output shown in Figure 10-9.

Table 10-5 describes the fields in the second line of output shown in Figure 10-9.

The third line in Figure 10-9 indicates the type of packet received and its source AppleTalk address. This message is repeated in the fourth line because AppleTalk hosts can send multiple replies to a given GetNetInfo request.

Debug Apple-Routing

Use the debug apple-routing command to enable debugging output from the Routing Table Maintenance Protocol (RTMP) routines. This command can be used to monitor acquisition of routes, aging of routing table entries, and advertisement of known routes. It also reports conflicting network numbers on the same network if the network is misconfigured.

Figure 10-10 shows example debug apple-routing output.

Explanations for representative lines of the debug apple-routing output in Figure 10-10 follow.

Table 10-6 describes the fields in the first line of example debug apple-routing output.

AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)

Table 10-7 describes the fields in the following line of debug apple-routing output.

AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0)

Debug Apple-ZIP

Use the debug apple-zip command to enable debugging output from the Zone Information Protocol (ZIP) routines. This command reports significant events such as discovery of new zones and zone list queries. It generates information similar to what debug apple-routing generates, but for ZIP packets instead of RTMP packets.

The debug apple-zip command can be used to determine whether a ZIP storm is taking place in the AppleTalk network. You can detect the existence of a ZIP storm when you see that no router on a cable has the zone name corresponding to a network number that all the routers have in their routing tables.

Figure 10-11 shows example debug apple-zip output.

Explanations of the lines of output shown in Figure 10-11 follow.

The first line indicates that the router has received an RTMP update that includes a new network number and is now requesting zone information.

AT: Sent GetNetInfo request broadcast on Ether0

The second line indicates that the neighbor at address 4160.19 replies to the zone request with a default zone.

AT: Recvd ZIP cmd 6 from 4160.19-6

In response, the third line shows that the router sends three queries to the neighbor at network address 4160.19 for other zones on the network.

AT: 3 query packets sent to neighbor 4160.19

The fourth line suggests that the neighbor at network address 4160.19 responds with a ZIP extended reply, indicating that one zone has been assigned to network 31902.

AT: 1 zones for 31902, ZIP XReply, src 4160.19

The fifth line indicates that the router responds that the zone name of network 31902 is US-Orlando, and the zone length of that zone name is 10.

AT: net 31902, zonelen 10, name US-Orlando

Debug ARP

Use the debug arp command to display information on ARP protocol transactions.

Use this command when some nodes on a TCP/IP network are responding, but others are not. It shows whether or not the router is sending or receiving ARPs.

Figure 10-12 shows example debug arp output.

In Figure 10-12, each line of output represents an ARP packet that the router sent or received. Explanations for the individual lines of output follow.

The first line indicates that the router at IP address 131.108.22.7 and MAC address 0000.0c01.e117 sent an ARP request for the MAC address of the host at 131.108.22.96. The series of zeros (0000.0000.0000) following this address indicate that the router is currently unaware of the MAC address.

IP ARP: sent req src 131.108.22.7 0000.0c01.e117, dst 131.108.22.96 \
0000.0000.0000

The second line indicates that the router at IP address 131.108.22.7 receives a reply from the host at 131.108.22.96 indicating that its MAC address is 0800.2010.b908.

IP ARP: rcvd rep src 131.108.22.96 0800.2010.b908, dst 131.108.22.7

The third line indicates that the router receives an ARP request from the host at 131.108.6.10 requesting the MAC address for the host at 131.108.6.62.

IP ARP: rcvd req src 131.108.6.10 0000.0c00.6fa2, dst 131.108.6.62

The fourth line indicates that another host on the network attempted to send the router an ARP reply for the router's own address. The router ignores such bogus replies. This usually can happen if someone is running a bridge in parallel with the router and is allowing ARP to be bridged. It indicates a network misconfiguration.

IP ARP: rep filtered src 131.108.22.7 aa92.1b36.a456, dst 255.255.255.255 \
ffff.ffff.ffff 

The fifth line indicates that another host on the network attempted to inform the router that it is on network 131.108.9.0, but the router does not know that that network is attached to a different router interface. The remote host (probably a PC or an X terminal) is misconfigured. If the router were to install this entry, it would deny service to the real machine on the proper cable.

IP ARP: rep filtered src 131.108.9.7 0000.0c00.6b31, dst 131.108.22.7 \
0800.2010.b908

Debug Broadcast

Use the debug broadcast command to debug MAC broadcast packets.

Depending on the type of interface and the type of encapsulation used on that interface, the debug broadcast command can produce a wide range of messages.

Figure 10-13 shows example debug broadcast output. Notice how similar it is to the debug packet output shown in Figure 10-34.

Table 10-8 describes significant fields shown in Figure 10-13.

Debug DECnet-Connects

Use the debug decnet-connects command to enable logging of all connect packets that are filtered (permitted or denied) by DECnet access lists.

When using connect packet filtering, it may be helpful to use the decnet access-group configuration command to apply the following basic access list:

access-list 300 permit 0.0 63.1023
access-list 300 permit 0.0 63.1023 eq any

You can then log all connect packets transmitted on interfaces to which you applied this list, in order to determine those elements on which your connect packets must be filtered.

Figure 10-14 shows example debug decnet-connect output.

Table 10-9 describes significant fields shown in Figure 10-14.

Debug Frame-Relay

Use the debug frame-relay command to analyze the packets that have been received on a frame relay interface. (To analyze the packets that have been sent on a frame relay interface, use the debug frame-relay-packets command.)

Figure 10-15 shows example debug frame-relay output.

Table 10-10 describes significant fields shown in Figure 10-15.

Debug Frame-Relay-Events

Use the debug frame-relay-events command to display information about frame relay ARP replies on networks that support a multicast channel and use dynamic addressing.

This command is most useful for identifying the cause of end-to-end connection problems during the installation of a frame relay network or node.

Figure 10-16 shows example debug frame-relay-events output.

As Figure 10-16 suggests, frame-relay-events returns one specific message type. The first line, for example, indicates that IP address 131.108.170.26 sent a frame relay ARP reply; this packet was received as input on the Serial2 interface. The last field (126) is the DLCI to use when communicating with the responding router.

Debug Frame-Relay-LMI

Use the debug frame-relay-lmi command to display information on the local management interface (LMI) packets exchanged by the router and the frame relay service provider.

You can use this command to determine whether the router and the frame relay switch are sending and receiving LMI packets properly.

Figure 10-17 shows example debug frame-relay-lmi output.

In Figure 10-17, the first three lines describe an LMI exchange. The first line describes the LMI request the router has sent to the switch. The second and third lines describe the response to this request from the switch. This LMI exchange is followed by two similar LMI exchanges. The last five lines in Figure 10-17 comprise a full LMI status message that includes a description of the router's two PVCs.

Table 10-11 describes significant fields in the first line of the debug frame-relay-lmi output shown in Figure 10-17.

Table 10-12 describes significant fields in the second and third lines of debug frame-relay-lmi output shown in Figure 10-17.

Table 10-13 describes significant fields in the last line of debug frame-relay-lmi output shown in Figure 10-17.

Debug Frame-Relay-Packets

Use the debug frame-relay-packets command to analyze the packets that have been sent on a frame relay interface. (To analyze the packets that have been received on a frame relay interface, use the debug frame-relay command.)

Figure 10-18 shows example debug frame-relay-packets output.

As Figure 10-18 shows, debug frame-relay-packets output is made up of groups of output lines; each group describes a frame relay packet that has been sent. The number of lines in the group can vary, depending on the number of DLCIs on which the packet was sent. For example, the first two pairs of output lines describe two different packets, both of which were sent out on a single DLCI. The last three lines in Figure 10-18 describe a single frame relay packet that was sent out on two DLCIs.

Table 10-14 describes significant fields shown in the first pair of output lines in Figure 10-18.

The discussion that follows describes the other lines of debug frame-relay-packet output shown in Figure 10-18.

The following group of output lines describes a frame relay packet sent to a particular address; in this case AppleTalk address 10.2.

Serial0: broadcast - 0, link 809B, addr 10.2
Serial0(o):DLCI 100 type 809B size 104

The following group of output lines describes a frame relay packet sent to a true broadcast address.

Serial1: broadcast search
Serial1(o):DLCI 400 type 800 size 288

The following group of output lines describes a frame relay packet that went out on two different DLCIs, because two frame relay map entries were found.

Serial0: broadcast search
Serial0(o):DLCI 300 type 809B size 24
Serial0(o):DLCI 400 type 809B size 24

Debug IP-ICMP

Use the debug ip-icmp command to enable logging of ICMP transactions.

This command is useful for determining whether the router is sending and/or receiving ICMP messages, when troubleshooting an end-to-end connection problem, for example.

Figure 10-19 shows example debug ip-icmp output.

Table 10-15 describes significant fields shown in the first line of debug ip-icmp output shown in Figure 10-19.

Table 10-16 describes significant fields shown in the second line of debug ip-icmp output in Figure 10-19.

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

ICMP: mask reply 255.255.255.0 from 160.89.80.31
ICMP: unexpected mask reply 255.255.255.0 from 160.89.80.32

ICMP: redirect sent to 160.89.80.31 for dest 131.108.1.111 use gw 160.89.80.23

ICMP: redirect rcvd from 160.89.80.23 -- for 160.89.81.34 use gw 160.89.80.28

ICMP: dst (131.108.13.33) host unreachable sent to 160.89.94.31

ICMP: dst (131.108.13.33) host unreachable rcv from 160.89.98.32

Depending on the code received (as Table 10-15 describes), any of the unreachable messages can have any of the following 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 128.95.1.4 (dest was 131.108.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. Fields are self-explanatory.

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

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

ICMP: parameter problem rcvd 160.89.80.32
ICMP: source quench rcvd 160.89.80.32
ICMP: source quench sent to 128.121.1.50 (dest was 131.108.1.111)
ICMP: sending time stamp reply to 160.89.80.45
ICMP: sending info reply to 160.89.80.12
ICMP: rdp advert rcvd type 9, code 0, from 160.89.80.23
ICMP: rdp solicit rcvd type 10, code 0, from 160.89.80.43

Debug IP-IGRP

Use the debug ip-igrp command to display IGRP routing transactions.

Syntax for the debug ip-igrp command follows.

If the IP address of an IGRP neighbor is specified, the resulting debug ip-igrp output will include messages describing updates from that neighbor and updates that the router broadcasts toward that neighbor.

When there are many networks in your routing table, debug ip-igrp can flood the console and make the router unusable. In this case, use debug ip-igrp-events instead to display summary routing information.

Figure 10-20 shows example debug ip-igrp output.

Figure 10-20 shows that the router being debugged has received updates from two other routers on the network. The router at source address 160.89.80.240 sent information about 10 destinations in the update; the router at source address 160.89.80.28 sent information about three destinations in its update. The router being debugged also sent updates--in both cases to the broadcast address 255.255.255.255 as the destination address.

The first line in Figure 10-20 is self explanatory.

On the second line in Figure 10-20, the first field refers to the type of destination information: "subnet" (interior), "network" (system) or "exterior" (exterior). The second field is the Internet address of the destination network. The third field is the metric stored in the routing table and the metric advertised by the neighbor sending the information. "Metric ... inaccessible" usually means that the neighbor router has put the destination in holddown.

The entries in Figure 10-20 showing that the router is sending updates are similar, except that the numbers in parentheses are the source addresses used in the IP header. A metric of 16777215 is inaccessible.

Other examples of output that the debug ip-igrp command can produce follow.

The following entry indicates that the routing table was updated and shows the new edition number (97 in this case) to be used in the next IGRP update.

IGRP: edition is now 97

Entries such as the following occur on startup or when some event occurs such as an interface transitioning or a user manually clearing the routing table.

IGRP: broadcasting request on Ethernet0
IGRP: broadcasting request on Ethernet1

The following type of entry can result when routing updates become corrupted between sending and receiving routers.

IGRP: bad checksum from 160.89.64.43

An entry such as the following should never appear. If it does, the receiving router has a bug in the software or a problem with the hardware. In either case, contact your technical support representative.

IGRP: system 45 from 160.89.64.234, should be system 109

Debug IP-IGRP-Events

Use the debug ip-igrp-events command to display summary IGRP routing messages that indicate the source and destination of each update, as well as the number of routes in each update. Messages are not generated for each route.

Syntax for the debug ip-igrp-events command follows.

If the IP address of an IGRP neighbor is specified, the resulting debug ip-igrp-events output will include messages describing updates from that neighbor and updates that the router broadcasts toward that neighbor.

This command is particularly useful when there are many networks in your routing table. In this case, using debug ip-igrp could flood the console and make the router unusable. Use debug ip-igrp-events instead to display summary routing information.

Figure 10-21 shows example debug ip-igrp-events output.

Figure 10-21 shows that the router has sent two updates to the broadcast address 255.255.255.255. The router also received two updates. Three lines of output describe each of these updates. Explanations for representative lines of output from Figure 10-20 follow.

The first line of output, as follows, indicates whether the router sent or received the update packet, the source or destination address, and the interface through which the update was sent or received. If the update was sent, the IP address assigned to this interface is shown (in parentheses).

IGRP: sending update to 255.255.255.255 via Ethernet1 (160.89.33.8)

The second line of output summarizes the number and types of routes described in the update.

IGRP: Update contains 26 interior, 40 system, and 3 exterior routes.

The third line of output indicates the total number of routes described in the update.

IGRP: Total routes in update: 69

Debug IP-OSPF-Events

Use the debug ip-ospf-events command to generate information concerning OSPF- related events, such as adjacencies, flooding information, designated router selection, and SPF calculation.

Figure 10-22 shows example debug ip-ospf-events output.

The debug ip-ospf-events output shown in Figure 10-22 might appear if any of the following occurs:

• The IP subnet masks for routers on the same network do not match.

• The OSPF Hello interval for the router does not match that configured for a neighbor.

• The OSPF Dead interval for the router does not match that configured for a neighbor.

If a router configured for OSPF routing is not seeing an OSPF neighbor on an attached network, do the following:

• Make sure that both routers have been configured with the same IP mask, OSPF Hello interval, and OSPF dead interval.

• Make sure that the both neighbors are part of same kind of area.

In the following example line, the neighbor and this router are not part of a stub area (that is, one is a part of transit area and the other is a part of stub area, as explained on page 92 of RFC 1247).

OSPF: hello packet with mismatched E bit

Debug IP-Packet

Use the debug ip-packet command to display general IP debugging information and IPSO security transactions.

If a communication session is closing when it should not be, an end-to-end connection problem can be the cause. The debug ip-packet command is useful for analyzing the messages traveling between the local and remote hosts.

IP debugging information includes packets received, generated, and forwarded. Fast-switched packets do not generate messages.

IPSO security transactions include messages that describe the cause of failure each time a datagram fails a security test in the system. This information also is sent to the sending host when the router configuration allows it.

The syntax for the debug ip-packet command follows:

In this syntax statement, list is an optional IP access list that you can specify. If the datagram is not permitted by that access list, the related debugging output is suppressed.

Figure 10-23 shows example debug ip-packet output.

Figure 10-23 shows two types of messages that debug ip-packet can produce; the first line of output describes an IP packet that the router forwards, and the third line of output describes a packet that is destined for the router. In the third line of output, "rcvd 2" indicates that the router decided to receive the packet.

Table 10-17 describes the fields shown in the first line of Figure 10-23.

The calculation on whether to send an security error message can be somewhat confusing. It depends upon both the security label in the datagram and the label of the incoming interface. First, the label contained in the datagram is examined for anything obviously wrong. If nothing is wrong, it should be assumed to be correct. If there is something wrong, the datagram should be treated as unclassified genser. Then this label is compared with the interface range, and the appropriate action is taken, as Table 10-18 describes.

The range of ICMP error messages that can be generated by the security code is very small. The only possible error messages and their meanings follow:

• "ICMP Parameter problem, code 0"--Error at pointer.

• "ICMP Parameter problem, code 1"--Missing option.

• "ICMP Parameter problem, code 2"--See Note that follows.

• "ICMP Unreachable, code 10"--Administratively prohibited.

Debug IP-RIP

Use the debug ip-rip command to enable logging of RIP routing transactions.

Figure 10-24 shows example debug ip-rip output.

Figure 10-24 shows that the router being debugged has received updates from one router at source address 160.89.80.28. That router sent information about five destinations in the routing table update. Notice that the fourth destination address in the update--131.108.0.0--is inaccessible because it is more than 15 hops away from the router sending the update. The router being debugged also sent updates--in both cases to the broadcast address 255.255.255.255 as the destination address.

The first line in Figure 10-24 is self-explanatory.

The second line in Figure 10-24 is an example of a routing table update. It shows how many hops a given Internet address is from the router.

The entries in Figure 10-24 showing that the router is sending updates are similar, except that the number in parentheses is the source address encapsulated into the IP header.

Examples of additional output that the debug ip-rip command can generate follow.

Entries such as the following appear at startup or when some event occurs such as an interface transitioning or the user manually clearing the routing table.

RIP: broadcasting general request on Ethernet0
RIP: broadcasting general request on Ethernet1

The following line is self-explanatory.

RIP: received request from 160.89.80.207 on Ethernet0

An entry such as the following is most likely caused by a malformed packet from the transmitter.

RIP: bad version 128 from 160.89.80.43

Debug IP-TCP

Use the debug ip-tcp command to display significant TCP transactions such as state changes, retransmissions, and duplicate packets.

This command is particularly useful for debugging a performance problem on a TCP/IP network that you have isolated above the data link layer.

The debug ip-tcp command displays output for packets the router sends and receives, but does not display output for packets it forwards.

Figure 10-25 shows example debug ip-tcp output.

Table 10-19 describes significant fields shown in Figure 10-25.

Debug LAPB

Use the debug lapb command to display all traffic for interfaces using LAPB encapsulation. This command displays information on the X.25 layer 2 protocol. It is useful to users who are familiar with the LAPB protocol.

You can use debug lapb to determine why X.25 virtual circuits or LAPB connections are going up and down. It is also useful for identifying link problems, as evidenced when show interface displays a high number of rejects or frame errors over the X.25 link.

Figure 10-26 shows example debug lapb output.

In Figure 10-26, each line of output describes a LAPB event. There are two types of LAPB events: frame events (when a frame enters or exits the router) and timer events. In Figure 10-26, the last line describes a timer event; all of the other lines describe frame events. Table 10-20 describes the first six fields shown in Figure 10-26.

Debug LNM-Events

Use the debug lnm-events command to display any unusual events that occur on a Token Ring network. This includes such things as stations reporting errors, error thresholds being exceeded, and so on.

Figure 10-27 shows sample debug lmn-events output.

Explanations for the messages shown in Figure 10-27 follow.

The following message indicates that station 0000.0300.1234 reported errors and has been added to the list of stations reporting errors. This station is located on Ring 3.

IBMNM3: Adding 0000.0300.1234 to error list

The following message indicates that the station has passed the "early warning" threshold for error counts.

IBMNM3: Station 0000.0300.1234 going into preweight condition

The following message indicates that station 0000.0300.1234 is experiencing a severe number of errors.

IBMNM3: Station 0000.0300.1234 going into weight condition

The following message indicates that the station's error counts have all decayed to zero, so this station is being removed from the list of stations that have reported errors.

IBMNM3: Removing 0000.0300.1234 from error list

The following message indicates that Ring 0 has entered failure mode. This ring number is assigned internally.

LANMGR0: Beaconing is present on the ring.

The following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned internally.

LANMGR0: Ring is no longer beaconing

The following message indicates that the router is beginning its attempt to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. The router attempts to contact stations that were part of the fault domain to see if they are still operating on the ring.

IBMNM3: Beaconing, Postmortem Started

The following message indicates that the router is attempting to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It heard back from station 0000.0300.1234, one of the two stations in the fault domain.

IBMNM3: Beaconing, heard from 0000.0300.1234

The following message indicates that the router is attempting to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It is initiating another attempt to contact the two stations in the fault domain.

IBMNM3: Beaconing, Postmortem Next Stage

The following output indicates that the router has attempted to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It has successfully heard back from both stations that were part of the fault domain.

IBMNM3: Beaconing, Postmortem Finished

Explanations for other messages that the debug lnm-events command can generate follow.

The following message indicates that the router is out of memory.

LANMGR: memory request failed, find_or_build_station()

The following message indicates that Ring number 3 is experiencing a large number of errors that cannot be attributed to any individual station.

IBMNM3: Non-isolating error threshold exceeded

The following message indicates that a station (or stations) on Ring 3 are receiving frames faster than they can be processed.

IBMNM3: Adapters experiencing congestion

The following message indicates that the beaconing has lasted for over one minute and is considered to be a "permanent" error.

IBMNM3: Beaconing, permanent

The following message indicates that the beaconing lasted for less than one minute. The router is attempting to determine whether either of the stations in the fault domain left the ring.

IBMNM: Beaconing, Destination Started

In the preceding line of output, the following can replace Started: Next State; Finished; Timed out; and cannot find station 0000.0301.4876.

Debug LNM-LLC

Use the debug lnm-llc command to display all communication between the router/bridge and the LNMs that have connections to it. One line is displayed for each message sent or received.

Figure 10-28 shows sample debug lnm-llc output.

As Figure 10-28 indicates, debug lmn-llc output can vary somewhat in format. Table 10-21 describes significant fields shown in the first line of output in Figure 10-28.

Explanations for other types of messages shown in Figure 10-28 follow.

The following message indicates that the lookup for the bridge with which the LAN Manager was requesting to communicate was successful.

IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630

The following message is self-explanatory.

IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0

The following message indicates that a LAN Manager has connected or disconnected from an internal bridge, and that the router computes which LAN Manager is allowed to change parameters.

IBMNM: Determining new controlling LNM

The following line of output indicates which bridge in the router is the destination for the frame.

IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.

Debug LNM-MAC

Use the debug lnm-mac command to display all management communication between the router/bridge and all stations on the local Token Rings. One line is displayed for each message sent or received.

Figure 10-29 shows sample debug lnm-mac output.

Table 10-22 describes significant fields shown in the first line of output in Figure 10-29.

As Figure 10-29 indicates, all debug lnm-mac messages follow the format described in Table 10-22 except the following:

LANMGR2: RS start watching ring poll
LANMGR2: RS stop watching ring poll

This message indicates that the router stops receiving AMP and SMP frames. These frames are used to build a current picture of which stations are on the ring.

Debug Local-ACK-State

Use the debug local-ack-state command to print out the new and the old state conditions whenever there is a state change in the Local Acknowledgment state machine.

Figure 10-30 shows example debug local-ack-state output.

Table 10-23 describes significant fields shown in Figure 10-30.

Debug Novell-Packet

Use the debug novell-packet command to output information about packets received, transmitted, and forwarded.

This command is useful for learning whether Novell packets are traveling over a router.

Figure 10-31 shows example debug novell-packet output.

In Figure 10-31, the first line indicates that the router receives a packet from a Novell station (address 160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet to this router. In the second line, the router forwards the packet toward the Novell server (address 1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).

Table 10-24 describes significant fields shown in Figure 10-31.

Debug Novell-Routing

Use the debug novell-routing command to print out information on Novell routing packets that the router sends and receives.

Figure 10-32 shows example debug novell-routing output.

Table 10-25 describes significant fields shown in Figure 10-32.

Debug Novell-SAP

Use the debug novell-sap command to display additional information about Novell Service Advertisement (SAP) packets.

Normally, a router or server sends out one SAP update per minute. Each SAP packet can include up to seven entries. If many servers are advertising on the network, the router sends out multiple packets per update. For example, if a router has 20 entries in the SAP table, it would send three SAP packets per update. The first SAP would include the first seven entries, the second SAP would include the next seven entries, and the last update would include the last six entries.

Figure 10-33 shows example debug novell-sap output.

As Figure 10-33 shows, the debug novell-sap command generates multiple lines of output for each SAP packet--a packet summary message and a service detail message.

Explanations for representative lines of output from Figure 10-33 follow.

The first line of output displays the internal router memory address of the packet. Cisco support staff use this information in problem debugging.

NovellSAP: at 0023F778:

Table 10-26 describes the fields shown in the second line of output in Figure 10-33.

Table 10-27 describes the fields shown in the third line of output in Figure 10-33.

NovellSAP: sending update to 160

As Figure 10-33 shows, the format for debug novell-sap output describing a SAP update the router sends is similar to that describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the following line of output from Figure 10-33 indicates.

O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)

Table 10-28 describes possible values for the ssoc: field.

Debug Packet

Use the debug packet command to log packets that the network is unable to classify.

Figure 10-34 shows example debug packet output. Notice how similar it is to debug broadcast output.

Table 10-29 describes significant fields shown in Figure 10-34.

Debug RIF

Use the debug rif command to provide informational displays for entries entering and leaving the RIF cache.

Figure 10-35 shows example debug rif output.

Explanations for representative lines of debug rif output in Figure 10-35 follow.

The first line of output in Figure 10-35 is an example of a RIF entry for an interface configured for SDLLC or Local-ACK.

Table 10-30 describes significant fields shown in this line of debug rif output.

The second line of output in Figure 10-35 is an example of a RIF entry for an interface that is not configured for SDLLC or Local-ACK.

RIF: U chk da=0000.3080.4aed,sa=0000.0000.0000 [] type 8 on TokenRing0/0

Notice that the source address contains only zero values (0000.0000.0000), and that the RIF string is null ([ ]). The last element in the entry indicates that this route was learned from a virtual ring, rather than a real Token Ring port.

The third line of output in Figure 10-35 shows that a new entry has been added to the RIF cache.

RIF: U add 1000.5a59.04f9 [4880.3201.00A1.0050] type 8

The fourth line of output in Figure 10-35 shows that a RIF cache lookup operation has taken place.

RIF: L checking da=0000.3080.4aed, sa=0000.0000.0000

The fifth line of output in Figure 10-35 shows that a TEST response from address 9000.5a59.04f9 was inserted into the RIF cache.

RIF: rcvd TEST response from 9000.5a59.04f9

The sixth line of output in Figure 10-35 shows that the RIF entry for this route has been found and updated.

RIF: U upd da=1000.5a59.04f9,sa=0110.2222.33c1 [4880.3201.00A1.0050]

The seventh line of output in Figure 10-35 shows that an XID response from this address was inserted into the RIF cache.

RIF: rcvd XID response from 9000.5a59.04f9

The eighth line of output in Figure 10-35 shows that the router sent an XID response to this address.

SR1: sent XID response to 9000.5a59.04f9

Table 10-31 explains the other possible lines of debug rif output.

Debug Serial-Interface

Use the debug serial-interface command to debug a serial connection failure.

If the show interface command shows that the line and protocol are down, you can use the debug serial-interface command to isolate a timing problem as the cause of a connection failure. If the keepalive values in the mineseq, yourseen, and myseen fields are not incrementing in each subsequent line of output, there is a timing or line problem at one of the ends of the connection.

The output of debug serial-interface command can vary, depending on the type of WAN configured for an interface: DDR, Frame Relay, HDLC, HSSI, SMDS, or X.25. The output also can vary depending on the type of encapsulation configured for that interface. The hardware platform also can impact debug serial-interface output.

The following sections show example debug serial-interface displays for various configurations and describe the possible output the command can generate for these configurations.

Debug Serial-Interface for DDR

Table 10-32 describes the error messages the debug serial-interface command can generate for a serial interface being used as a V.25bis dialer for dial-on-demand routing.

Debug Serial-Interface for Frame Relay Encapsulation

The following message is displayed if the encapsulation for the interface is frame relay (or HDLC) and the router attempts to send a packet containing an unknown packet type.

Illegal serial link type code xxx

Debug Serial-Interface for HDLC

Figure 10-36 shows example debug serial-interface output for an HDLC connection when keepalives have been enabled.

In Figure 10-36, the debug serial-interface display shows that the remote router is not receiving all of the keepalives the router is sending. When the difference in the values in the myseq and mineseen fields exceeds three, the line goes down and the interface is reset.

Table 10-33 describes significant fields shown in Figure 10-36.

Table 10-34 describes additional error messages that the debug serial-interface command can generate for HDLC.

Debug Serial-Interface for HSSI

On an HSSI interface, the debug serial-interface command can generate the following additional error message:

HSSI0: Reset from 0xnnnnnnn

This message indicates that the HSSI hardware has been reset. The 0xnnnnnnn variable is the address of the routine requesting that the hardware be reset; this value is useful only to development engineers.

Debug Serial-Interface for ISDN Basic Rate

Table 10-35 describes error messages that the debug serial-interface command can generate for ISDN Basic Rate.

Debug Serial-Interface for an MK5025 Device

Table 10-36 describes the additional error messages that the debug serial-interface command can generate for an MK5025 device.

Debug Serial-Interface for PPP Encapsulation

Figure 10-37 lists all of the messages that the debug serial-interface command can generate when the encapsulation is set to PPP and PPP is negotiating configuration options.

A knowledge of the PPP protocol is necessary to understand the significance of the messages listed in Figure 10-37.

Figure 10-38 lists the debug serial-interface messages that can be displayed when CHAP is enabled on a PPP interface.

The messages listed in Figure 10-38 indicate the current state of CHAP negotiation.

Debug Serial-Interface for SMDS Encapsulation

When encapsulation is set to SMDS, debug serial-interface displays SMDS packets that have been sent and received, as well as any error messages resulting from SMDS packet transmission.

The error messages that the debug serial-interface command can generate for SMDS follow.

The following message indicates that a new protocol requested SMDS to encapsulate the data for transmission. SMDS does not know yet how to encapsulate the protocol.

SMDS: Error on Serial 0, encapsulation bad protocol = x

The following indicates that SMDS was asked to encapsulate a packet, but no corresponding destination E.164 SMDS address was found in any of the static SMDS tables or in the ARP tables.

SMDS send: Error in encapsulation, no hardware address, type = x

The following indicates that a protocol such as CLNS or IP has been enabled on an SMDS interface, but the corresponding multicast addresses have not been configured. The n variable displays the link type for which encapsulation was requested. This value is only significant to Cisco as an internal protocol type value.

SMDS: Send, Error in encapulation, type=n

The following messages can occur when a packet that was somehow corrupted is received on an SMDS interface. The router expected x, but received y.

SMDS: Invalid packet, Reserved NOT ZERO, x y
SMDS: Invalid packet, TAG mismatch x y
SMDS: Invalid packet, Bad TRAILER length x y

The following messages can indicate an invalid length for an SMDS packet.

SMDS: Invalid packet, Bad BA length x
SMDS: Invalid packet, Bad header extension length x
SMDS: Invalid packet, Bad header extensiontype x
SMDS: Invalid packet, Bad header extension value x

The following messages are displayed when debug serial-interface is enabled.

Interface Serial 0 Sending SMDS L3 packet:
SMDS: dgsize:x type:0xn src:y dst:z

If debug serial-interface is enabled, the following message can be displayed when a packet is received on an SMDS interface, but the destination SMDS address does not match any on that interface.

SMDS: Packet n, not addressed to us

Debug Serial-Packet

Use the debug serial-packet command to provide more detailed serial interface debugging information than you can obtain using debug serial-interface.

The debug serial-packet command generates output that is dependent on the type of serial interface and the encapsulation that is running on that interface. The hardware platform also can impact debug serial-packet output.

Currently, the debug serial-packet command displays output for only DDR, PPP, and SMDS encapsulations.

Debug Serial-Packet for DDR

When you enable debug serial-packet and DDR is enabled on the interface, information concerning the cause of any calls (called Dialing cause) may be displayed.

The following line of output for an IP packet lists the name of the DDR interface and the source and destination addresses of the packet.

Dialing cause: Serial0: ip (s=131.108.1.111 d=131.108.2.22)

The following line of output for a bridged packet lists the DDR interface and the type of packet (in hexadecimal). For information on these packet types, see Appendix C, "Ethernet Type Codes," of the Router Products Configuration and Reference publication.

Dialing cause: Serial1: Bridge (0x6005)

Debug Serial-Packet for PPP

Figure 10-39 shows example debug serial-packet output when PPP is enabled on the interface.

Table 10-37 describes significant fields shown in Figure 10-39.

PPP send: on Serial0 STATE= 4 LINK= ppp-lcp, CODE= 5, ID= 345, LEN = 9

ppp: TIMEout: Time= 3245532 State= 4

ppp: rcvd short header for ppp-lcp
ppp: rcvd illegal length for ppp-lcp
ppp: rcvd short packet. len x > y for ppp-lcp

PPP input(ppp-lcp): state = 4 code = 5 id = 345 len = 9

ppp: state = 4 fsm_rconfack(ppp-lcp): rcvd id 345

ppp: received config for type = x  value = y acked
ppp: received config for type = x  value = y rejected
ppp: received config for type = x  value = y nacked

Debug Serial-Packet for SMDS Encapsulation

Figure 10-40 shows example output when SMDS is enabled on the interface.

As Figure 10-40 suggests, when encapsulation is set to SMDS, debug serial-packet displays the entire SMDS header (in hex), as well as some payload data on transmit or receive. This information is useful only when you have an understanding of the SMDS protocol. The first line of the output indicates either Sending or Receiving.

Debug Source-Event

Use the debug source-event command to provide informational displays of source bridging activity. (Output of the debug source-bridge command is identical to the output of this command.)

Figure 10-41 shows example debug source-event output.

Table 10-38 describes significant fields shown in Figure 10-41.

SRBn: no path, s: <src MAC addr>d: <dst MAC addr>rif: <rif>

SRBn: direct forward (srn <ring>bn <bridge>trn <ring>)

SRBn: br dropped proxy XID,  <address>for <address>, wrong vring (rem)
SRBn: br dropped proxy TEST, <address>for <address>, wrong vring (rem)
SRBn: br dropped proxy XID,  <address>for <address>, wrong vring (local)
SRBn: br dropped proxy TEST, <address>for <address>, wrong vring (local)
SRBn: br dropped proxy XID,  <address>for <address>, no path
SRBn: br dropped proxy TEST, <address>for <address>, no path

SRBn: br sent proxy XID,  <address>for <address>[<rif>]
SRBn: br sent proxy TEST, <address>for <address>[<rif>]

SRB<unit#>: illegal explorer, s: <srcMACaddr> d: <destMACaddr> rif:
<RIFstring>

SRB<unit #>: bad explorer control, D set or odd

SRB<unit #>: span dropped, input off, s: <src mac addr> d: <dest mac addr>
rif: <rif string>

SRB<unit #>: span violation, s: <src mac addr> d: <dest mac addr> rif:
<rif string>

SRB<unit #>: max hops reached - <hop cnt>, s: <src mac addr> d: <dest mac addr>
rif: <rif string>

RSRB: sent RingXreq to <ring group>/<ip addr>

RSRB: <label>: sent <op>to <ring group>/<ip addr>

RSRB: removing bn <bridge>rn <ring>from <ring group>/<ip addr>
RSRB: added bridge <bridge>, ring <ring>for <ring group>/<ip addr>

RSRB: peer <ring group>/<ip addr>closed [last state n
RSRB: passive open <ip addr>(remote port) -><local port>
RSRB: CONN: opening peer <ring group>/<ip addr>, attempt n
RSRB: CONN: Remote closed <ring group>/<ip addr>on open
RSRB: CONN: peer <ring group>/<ip addr>open failed, <reason>[code]

RSRBn: sent local explorer, bridge <bridge>trn <ring>, [rif]

RSRBn: ring group <ring group>not found
RSRBn: explorer rif [rif] not long enough

RSRB: couldn't get pak for ringXchg

RSRB: XCHG: req/reply badly formed, length <pak length>, peer <peer id>

RSRB: removing bridge <br #> ring <ring #> from <peer name> <ring type>

RSRB: added bridge <br #>, ring <ring #> for <peer id>

RSRB: no memory for ring element <ring group #>

RSRB: CONN: corrupt connection block

RSRB: CONN: warning, no initial packet, peer: <ip addr> <peer pointer>

RSRB: IF New version. local=<local version #>, remote=<remote version>,
<pak op code> <peer id>

RSRB: IFin: bad op <op code> (op code string) from <peer id>

RSRB: vrif_sender, hdr won't fit

RSRB: CONN: opening peer <peer id> <retry count>

RSRB: FST Rcvd version reply from <peer id> (version #)

RSRB: FST Version Request. op = <opcode>, <peer id>

RSRB: FSTin: bad op <opcode> (op code string) from <peer id>

RSRB: aborting <ring group #>/<peer id> (vrtcpd_abort called)

RSRB: CONN: attempt timed out

RSRB<unit #>: ring group <ring group #> not found

Debug Span

Use the debug span command to track changes in the spanning-tree topology when debugging a transparent bridge.

This command is useful for verifying that the spanning-tree protocol is operating correctly.

IEEE Spanning Tree Example

Example debug span output for an IEEE BPDU packet follows:

ST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00

Broken up by fields and labeled to aid documentation, the preceding debug span output appears as shown in Figure 10-42.

Table 10-39 describes significant fields shown in this debug span output.

DEC Spanning Tree Example

Example debug span output for a DEC BPDU packet follows:

ST: Ethernet4 E1190100000200000C01A2C90064008000000C0106CE0A01050F1E6A

Broken up by fields and labeled to aid documentation, this debug span output appears as shown in Figure 10-43.

Table 10-40 describes significant fields shown in this debug span output.

Debug TFTP

Use the debug tftp command to display TFTP debugging information when encountering problems netbooting or using the configure network or write network commands.

Figure 10-44 shows example debug tftp output from the EXEC command write network.

Table 10-41 describes significant fields shown in the first line of output from Figure 10-44.

Debug Token-Ring

Use the debug token-ring command to display messages about Token Ring interface activity. This command reports several lines of information for each packet sent or received and is intended for low traffic, detailed debugging.

The Token Ring interface records provide information regarding the current state of the ring. These messages are only displayed when debug token-events is enabled.

The debug token-ring command invokes verbose Token Ring hardware debugging. This includes detailed displays as traffic arrives and departs the unit.

Figure 10-45 shows example debug token-ring output.

Descriptions of example lines of output in Figure 10-45 follow.

Table 10-42 describes significant fields shown in the second line of output from Figure 10-45.

TR0:  in: MAC: acfc: 0x1105 Dst: c000.ffff.ffff Src: 5000.1234.5678  bf: 0x45

Table 10-43 describes significant fields shown in the third line of output from Figure 10-45.

TR0:  in:      riflen 0, rd_offset 0, llc_offset 40

Table 10-43 describes significant fields shown in the fifth line of output from Figure 10-45.

TR0: out: LLC: AAAA0300 00009000 00000100 AAC00000 00000802 50001234 ln: 28

Debug VINES-ARP

Use the debug vines-arp command to enable logging of all ARP packets that the router sends or receives.

Figure 10-46 shows example debug vines-arp output.

In Figure 10-46, the first line shows that the router received an ARP request (type 0) from station address 0260.8c43.a7e4. The second line shows that the router is sending back the ARP service response indicating that it is willing to assign VINES internet addresses. The third line shows that the router received a Vines internet address assignment request (type 2) from address 0260.8c43.a7e4. The fourth line shows that the router is responding (type 3) to the address assignment request from the client and assigning it the address 3001153C:8004.

Table 10-45 describes significant fields shown in Figure 10-46.

Debug VINES-Echo

Use the debug vines-echo command to enable logging of all MAC-level echo packets that the router sends or receives. Banyan interface testing programs make use of these echo packets.

Figure 10-47 shows example debug vines-echo output.

Table 10-46 describes the fields shown in Figure 10-47.

Debug VINES-Packet

Use the debug vines-packet command to enable logging of general VINES debugging information. This information includes packets received, generated, and forwarded, as well as failed access checks and other items.

Figure 10-48 shows example debug vines-packet output.

The following describes selected lines of output from Figure 10-48.

Table 10-47 describes the fields shown in the first line of output.

VINES: s=3000CBD4:1 (Ether1), d=3002ABEA:1 (Ethernet2), g=3002ABEA:1, sent

VINES: s=3000CBD4:1 (Ether1), d=3000B959:1, rcvd by gw

VINES: received vines IPC Disc from 3000CBD4:1

VINES: s=3000B959:1 (local), d=3000CBD4:1 (Ether1), g=3000CBD4:1, sent

Debug VINES-Routing

Use the debug vines-routing command to enable logging of all RTP update messages sent or received and all routing table activities that occur in the router.

Figure 10-49 shows example debug vines-routing output.

Figure 10-49 describes two VINES routing updates; the first includes two entries and the second includes three entries. The following describes selected lines of output from Figure 10-49.

The following first line shows that the router sent a periodic routing update to the broadcast address FFFFFFFF:FFFF through the Ethernet3 interface.

VINESRTP: sending update to FFFFFFFF:FFFF on Ethernet3

The following second line indicates that the router knows how to reach network 3000073B, which is metric 2 away from the router. The value that follows the metric (0.4 seconds) interprets the metric in seconds.

network 3000073B, metric 2 (.4 seconds)

The following fourth line of output indicates that the router received a routing update from the VINES server at VINES address 27AF9A:1 through the Ethernet2 interface.

VINESRTP: received update from 27AF9A:1 on Ethernet2

The following fifth line of output implies that the server sending this update is directly accessible to the router (even though VINES servers do not explicitly list themselves in routing updates). Because this is an implicit entry in the table, there is no metric associated with this line of output.

network 27AF9A from the server

As the first actual entry in the routing update from the VINES server at 27AF9A:1, the following line indicates that network 30019AC7 can be reached by sending to this server. This network is a metric of 2 away from the sending server. The value that follows the metric (0.4 seconds) interprets the metric in seconds.

network 30019AC7, metric 2 (0.4 seconds)

Debug VINES-Table

Use the debug vines-table command to enable logging of all modifications to the VINES routing table. This command provides a subset of the information provided by the debug vines-routing command, as well as some more detailed information on table additions and deletions.

Figure 10-50 shows example debug vines-table output.

Table 10-48 describes significant fields shown in Figure 10-50.

Debug XNS-Packet

Use the debug xns-packet command to enable logging of XNS packet traffic, including the addresses for source, destination, and next hop router of each packet.

Figure 10-51 shows example debug xns-packet output.

Table 10-49 describes significant fields shown in Figure 10-51.

Debug XNS-Routing

Use the debug xns-routing command to display XNS routing transactions.

Figure 10-52 shows example debug xns-routing output.

Table 10-50 describes significant fields shown in Figure 10-52.

Debug X25

Use the debug x25 command to display all X.25 traffic.

This command is particularly useful for diagnosing problems encountered when placing CALLs.

While debug x25 output includes both data and control messages for all of the router's virtual circuits, debug x25-events output (discussed later in this chapter) includes only control messages for all of the router's VCs. In contrast, debug x25-vc output (also discussed later) includes only control messages for a particular VC. Thus, debug x25-events output is a subset of debug x25 output, and debug x25-vc output is a subset of debug x25-events output.

Caution Because debug x25 displays all X.25 traffic, it is very processor intensive and can render the router useless. You should only use debug x25 when the aggregate of all X.25 traffic is less than five packets per second.

Figure 10-53 shows example debug x25 output.

Figure 10-53 shows a typical exchange of packets between two X.25 devices on a network. The first line of output in Figure 10-53, reproduced below, describes a RESTART packet.

Serial2 (236414440): X25 O R3 RESTART (5) 8 lci 0 cause 7 diag 0

Table 10-51 describes the fields shown in this line of output.

Notice that the first DATA packet in Figure 10-53 contains two fields not yet documented.

Serial2 (236426444): X25 I P4 DATA (103) 8 lci 1024 PS 0 PR 0

Table 10-52 describes the PS and PR fields that can appear in a debug x25 display.

In Figure 10-53, notice also that the CALL REQUEST packet precedes two other lines of output that are unique in format.

Serial2 (236424436): X25 I P1 CALL REQUEST (11) 8 lci 1024
From(2): 49 To(2): 46
Facilities: (0)

These lines indicate that the CALL REQUEST packet has a two-digit source address, 49, and a two-digit destination address, 46. These are X.121 addresses that can be from 0 to 15 digits in length. The Facilities field is (0) bytes in length, indicating that no X.25 facilities are being requested.

Debug X25-Events

Use the debug x25-events command to display all X.25 traffic except X.25 data or acknowledgment packets.

The debug x25-events command is very useful for debugging X.25 problems, because it shows changes that occur in the virtual circuits handled by the router. Because most X.25 connectivity problems stem from errors that CLEAR or RESET virtual circuits, you can use debug x25-events to identify these errors.

While debug x25 output includes both data and control messages for all of the router's virtual circuits, debug x25-events output includes only control messages for all of the router's VCs. In contrast, debug x25-vc output includes only control messages for a particular VC. Thus, debug x25-events output is a subset of debug x25 output, and debug x25-vc output is a subset of debug x25-events output.

Figure 10-54 shows example debug x25-events output.

Debug X25-VC

Use the debug x25-vc command to display traffic for a particular virtual circuit in order to solve any connectivity or performance problems it is exhibiting.

Syntax for the debug x25-vc command follows.

In this syntax statement, number is the LCI number associated with the virtual circuit(s) you want to monitor. Because no interface is specified, traffic on any VC that has the specified number is reported.

While debug x25 output includes both data and control messages for all of the router's virtual circuits, debug x25-events output includes only control messages for all of the router's VCs. In contrast, debug x25-vc output includes only control messages for a particular VC. Thus, debug x25-events output is a subset of debug x25 output, and debug x25-vc output is a subset of debug x25-events output.

Figure 10-55 shows example debug x25-vc output.