Dapple

C H A P T E R
Debug Commands 2-1

Debug Commands
2
This chapter contains an alphabetical listing of the debug commands. Documentation for each
command includes a brief description of its use, command syntax, usage guidelines, sample output,
and a description of that output.
Output formats vary with each debug command. Some generate a single line of output per packet,
whereas others generate multiple lines of output per packet. Some generate large amounts of output;
others generate only occasional output. Some generate lines of text, and 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.
By default, the network server sends the output from the debug commands to the console terminal.
Sending output to a terminal (virtual console) produces less overhead than sending it to the console.
Use the privileged EXEC command terminal monitor to send output to a terminal. For more
information about redirecting output, see the Using Debug Commands chapter.
2-2 Debug Command Reference
debug aaa authentication
Use the debug aaa authentication command to display information on AAA/TACACS+
authentication. Use the no form of the command to disable debugging output.
no debug aaa authentication
Syntax Description
This command has no arguments of keywords.
Command Mode
EXEC
Usage Guidelines
Use this command to see what methods of authentication are being used and what the results of these
methods are.
Sample Display
Figure 2-1 shows sample debug aaa authentication output. A single EXEC login that uses the
"default" method list and the first method, TACACS+, is displayed. The TACACS+ server sends a
GETUSER request to prompt for the username and then a GETPASS request to prompt for the
password, and finally a PASS response to indicate a successful login. The number 50996740 is the
session ID, which is unique for each authentication. Use this ID number to distinguish between
different authentications if several are occuring concurrently.
Figure 2-1 Sample Debug AAA Authentication Output
router# debug aaa authentication
6:50:12: AAA/AUTHEN: create_user user='' ruser='' port='tty19' rem_addr='171.69.60.15'
authen_type=1 service=1 priv=1
6:50:12: AAA/AUTHEN/START (0): port='tty19' list='' action=LOGIN service=LOGIN
6:50:12: AAA/AUTHEN/START (0): using "default" list
6:50:12: AAA/AUTHEN/START (50996740): Method=TACACS+
6:50:12: TAC+ (50996740): received authen response status = GETUSER
6:50:12: AAA/AUTHEN (50996740): status = GETUSER
6:50:15: AAA/AUTHEN/CONT (50996740): continue_login
6:50:15: AAA/AUTHEN (50996740): status = GETUSER
6:50:15: AAA/AUTHEN (50996740): Method=TACACS+
6:50:15: TAC+: send AUTHEN/CONT packet
6:50:15: TAC+ (50996740): received authen response status = GETPASS
6:50:15: AAA/AUTHEN (50996740): status = GETPASS
6:50:20: AAA/AUTHEN/CONT (50996740): continue_login
6:50:20: AAA/AUTHEN (50996740): status = GETPASS
6:50:20: AAA/AUTHEN (50996740): Method=TACACS+
6:50:20: TAC+: send AUTHEN/CONT packet
6:50:20: TAC+ (50996740): received authen response status = PASS
6:50:20: AAA/AUTHEN (50996740): status = PASS
Debug Commands 2-3
debug aaa authorization
Use the debug aaa authorization command to display information on AAA/TACACS+
authorization. Use the no form of the command to disable debugging output.
no debug aaa authorization
Syntax Description
This command has no arguments of keywords.
Command Mode
EXEC
Usage Guidelines
Use this command to see what methods of authorization are being used and what the results of these
methods are.
Sample Display
Figure 2-2 shows sample debug aaa authorization output. In this display, an EXEC authorization
for user "carrel" is performed. On the first line, the username is authorized. On the second and third
lines, the AV (attribute value) pairs are authorized. The debug output displays a line for each attribute
value pair that is authenticated. Next, the display indicates the authorization method used. The final
line in the display indicates the status of the authorization process, in this case, a failure.
Figure 2-2 Sample Debug AAA Authorization Output
2:23:21: AAA/AUTHOR (0): user='carrel'
2:23:21: AAA/AUTHOR (0): send AV service=shell
2:23:21: AAA/AUTHOR (0): send AV cmd*
2:23:21: AAA/AUTHOR (342885561): Method=TACACS+
2:23:21: AAA/AUTHOR/TAC+ (342885561): user=carrel
2:23:21: AAA/AUTHOR/TAC+ (342885561): send AV service=shell
2:23:21: AAA/AUTHOR/TAC+ (342885561): send AV cmd*
2:23:21: AAA/AUTHOR (342885561): Post authorization status = FAIL
The aaa authorization command causes a request packet containing a series of attribute value pairs
to be sent to the TACACS daemon as part of the authorization process. The daemon responds in one
of three ways:
Accepts the request as is
Makes changes to the request
Refuses the request, thereby refusing authorization
Table 2-1 describes attribute value pairs associated with the aaa authorization command which
may show up in the debug output.
Note Registered users can find more information about TACACS+ and attribute pairs on Cisco
Information Online (CIO). Access to CIO is available through the World Wide Web at
http://www.cisco.com/ or through a telnet connection to cio.cisco.com.
Table 2-1 Attribute Value Pairs for Authorization
Attribute Value Description
service=arap Authorization for AppleTalk Remote Access is
being requested.
service=shell Authorization for EXEC startup and command
authorization is being requested.
service=ppp Authorization for PPP is being requested.
service=slip Authorization for SLIP is being requested.
protocol=lcp Authorization for LCP is being requested (lower
layer of PPP).
protocol=ip Used with service=slip and service=slip to indicate
which protocol layer is being authorized.
protocol=ipx Used with service=ppp to indicate which protocol
layer is being authorized.
protocol=atalk Used with service=ppp or service=arap to indicate
which protocol layer is being authorized.
protocol=vines Used with service=ppp for VINES over PPP.
protocol=unknown Used for undefined or unsupported conditions.
cmd=x Used with service=shell, if cmd=NULL, this is an
authorization request to start an EXEC. If cmd is
not NULL, this is a command authorization request
and will contain the name of the command being
authorized. For example, cmd=telnet.
cmd-arg=x Used with service=shell. When performing
command authorization, the name of the command
is given by a cmd=x pair for each argument listed.
For example, cmd-arg=archie.sura.net.
acl=x Used with service=shell and service=arap. For
ARA, this pair contains an access list number. For
service=shell, this pair contains an access class
number. For example, acl=2.
inacl=x Used with service=ppp and protocol=ip. Contains
an IP input access list for SLIP or PPP/IP. For
example, inacl=2.
outacl=x Used with service=ppp and protocol=ip. Contains
an IP output access list for SLIP or PPP/IP. For
example, outacl=4.
addr=x Used with service=slip, service=ppp, and
protocol=ip. Contains the IP address that the
remote host should use when connecting via SLIP
or PPP/IP. For example, addr=172.30.23.11.
Debug Commands 2-5
routing=x Used with service=slip, service=ppp, and
protocol=ip. Equivalent in function to the /routing
flag in SLIP and PPP commands. Can either be true
or false. For example, routing=true.
timeout=x Used with service=arap. The number of minutes
before an ARA session disconnects. For example,
timeout=60.
autocmd=x Used with service=shell and cmd=NULL. Specifies
an autocommand to be executed at EXEC startup.
For example, autocmd=telnet foo.com.
noescape=x Used with service=shell and cmd=NULL. Specifies
a noescape option to the username configuration
command. Can be either true or false. For example,
noescape=true.
nohangup=x Used with service=shell and cmd=NULL. Specifies
a nohangup option to the username configuration
command. Can be either true or false. For example.
nohangup=false.
priv-lvl=x Used with service=shell and cmd=NULL. Specifies
the current privilege level for command
authorization as a number from 0 to 15. For
example, priv-lvl=15.
zonelist=x Used with service=arap. Specifies an AppleTalk
zonelist for ARA. For example, zonelist=5.
addr-pool=x Used with service=ppp and protocol=ip. Specifies
the name of a local pool from which to get the
address of the remote host.
Attribute Value Description
debug apple arp
debug apple arp
Use the debug apple arp EXEC command to enable debugging of the AppleTalk Address
Resolution Protocol (AARP). The no form of this command disables debugging output.
debug apple arp [type number]
no debug apple arp [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command is helpful when you experience problems communicating with a node on the network
you control (a 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.
Sample Display
Figure 2-3 shows sample debug apple arp output.
Figure 2-3 Sample Debug Apple ARP Output
router# debug apple arp
Ether0: AARP: Sent resolve for 4160.26
Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9)
Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453)
Explanations for representative lines of output in Figure 2-3 follow.
type (Optional) Interface type.
number (Optional) Interface number.
Debug Commands 2-7
debug apple arp
The following line 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 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).
The following line indicates that the MAC address request is complete:
debug apple domain
debug apple domain
Use the debug apple domain EXEC command to enable debugging of the AppleTalk domain
activities. The no form of this command disables debugging output.
debug apple domain
no debug apple domain
Syntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Usage Guidelines
Use the debug apple domain command to observe activity for domains and subdomains. Use this
command in conjunction with the debug apple remap command to observe interaction between
remapping and domain activity. Messages are displayed when the state of a domain changes, such
as creating a new domain, deleting a domain, and updating a domain.
Sample Display
Figure 2-4 shows sample debug apple domain output intermixed with output from the debug apple
remap command; the two commands show related events.
Figure 2-4 Sample Debug Apple Domain Output
router# debug apple domain
router# debug apple remap
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1
AT-REMAP: ReshuffleRemapList for subdomain 1
AT-REMAP: Could not find a remap for cable 3000-3001
AT-DOMAIN: atdomain_DisablePort for Tunnel0
AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]
AT-DOMAIN: Disabling interface Ethernet1
AT-DOMAIN: atdomain_DisablePort for Ethernet1
AT-DOMAIN: CleanSubDomain for inbound subdomain 1
AT-REMAP: Remap for net 70 inbound subdomain 1 has been deleted
AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1
AT-DOMAIN: DeleteRemapTable for subdomain 1
AT-DOMAIN: CleanSubDomain for outbound subdomain 1
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1 Remaped Net 10000
AT-REMAP: Remap for net 50 outbound subdomain 1 has been deleted
AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1
Debug Commands 2-9
debug apple domain
Related Command
debug apple remap
debug apple errors
debug apple errors
Use the debug apple errors EXEC command to display errors occurring in the AppleTalk network.
The no form of this command disables debugging output.
debug apple errors [type number]
no debug apple errors [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
In a stable AppleTalk network, the debug apple errors command produces little output.
To solve encapsulation problems, enable debug apple errors and debug apple packet together.
Sample Display
Figure 2-5 shows sample 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.
Figure 2-5 Debug Apple Errors Output
router# debug apple errors
%AT-3-ZONEDISAGREES: Ethernet0: AppleTalk port disabled; zone list incompatible with
4160.19
4160.19
4160.19
As Figure 2-5 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 obscure or indicate a serious
problem with the AppleTalk network. Some of these other messages follow.
Debug Commands 2-11
debug apple errors
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, in addition to 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 additional messages when other debugging
commands are also turned on. When you turn on both debug apple errors and debug apple events,
the following message can be generated:
Proc err, src 4160.12-254,dst 4160.19-254,ZIP,NetInfo Reply format is invalid
In the preceding message, in addition to 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 you turn on both debug apple errors and debug apple nbp, the following message can be
generated:
Processing error, ...,NBP,NBP name invalid
In the preceding message, in addition to 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 you turn on both debug apple errors and debug apple routing, the following message can
be generated:
Processing error, ...,RTMPReq, unknown RTMP request
In the preceding message, in addition to 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
debug apple events
Use the debug apple events EXEC command to display information about AppleTalk special
events, neighbors becoming reachable/unreachable, and interfaces going up/down. Only significant
events (for example, neighbor and route changes) are logged. The no form of this command disables
debugging output.
debug apple events [type number]
no debug apple events [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug apple events command is 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 the command generates numerous messages,
those messages can indicate possible sources of the problems.
When configuring or making changes to a router or interface for AppleTalk, enable debug apple
events. Doing so alerts you to the progress of the changes or to any errors that might result. Also use
this command periodically when you suspect network problems.
The debug apple events command is also useful to determine whether network flapping (nodes
toggling online and offline) is occurring. If flapping is excessive, look for routers that only support
254 networks.
When you enable debug apple events, you will see any messages that the configuration command
apple event-logging normally displays. Turning on debug apple events, however, does not cause
apple event-logging to be maintained in nonvolatile memory. Only turning on apple event-logging
explicitly stores it in nonvolatile memory. Furthermore, if apple event-logging is already enabled,
turning on or off debug apple events does not affect apple event-logging.
Sample Display
Figure 2-6 shows sample debug apple events output that describes a nonseed router coming up in
discovery mode.
Debug Commands 2-13
debug apple events
Figure 2-6 Sample Debug Apple Events Output with Discovery Mode State Changes
As Figure 2-6 shows, the debug apple events command is useful in tracking the discovery mode
state changes through which an interface progresses. When no problems are encountered, the state
changes progress as follows:
1 Line down
2 Restarting
3 Probing (for its own address [node ID] using AARP)
4 Acquiring (sending out GetNetInfo requests)
5 Requesting zones (the list of zones for its cable)
6 Verifying (that the routers configuration is correct. If not, a port configuration mismatch is
declared.)
7 Checking zones (to make sure its list of zones is correct)
8 Operational (participating in routing)
Explanations for individual lines of output in Figure 2-6 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
router# debug apple events
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148
Ether0: AppleTalk state changed; probing -> acquiring
%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration
Ether0: AppleTalk state changed; acquiring -> restarting
Ether0: AppleTalk state changed; restarting -> line down
Ether0: AppleTalk state changed; line down -> restarting
Ether0: AppleTalk state changed; acquiring -> requesting zones
Ether0: AppleTalk state changed; requesting zones -> verifying
AT: Sent GetNetInfo request broadcast on Ethernet0
Ether0: AppleTalk state changed; verifying -> checking zones
Ether0: AppleTalk state changed; checking zones -> operational
Discovery
mode state
changes
S
2
5
4
2
debug apple events
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 discovery-enabled router; it is rarely the case for a nondiscovery-enabled router.
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 can be chosen:
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
The following message indicates that the router has found an actual network address to use:
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 can be
chosen:
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
The following message indicates that the router is rechecking its list of zones for its cable:
Ether0: 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:
Ether0: AppleTalk state changed; checking zones -> operational
Figure 2-7 shows sample debug apple events output that describes a nondiscovery-enabled router
coming up when no other router is on the wire.
Debug Commands 2-15
debug apple events
Figure 2-7 Sample Debug Apple Events Output Showing Seed Coming Up by Itself
As Figure 2-7 shows, a nondiscovery-enabled 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 2-7 indicates this situation.
Figure 2-8 shows sample debug apple events output that describes a discovery-enabled router
coming up when there is no seed router on the wire.
Figure 2-8 Debug Apple Events Output Showing Nonseed with No Seed
AT: Sent GetNetInfo request broadcast on Ether0
As Figure 2-8 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 2-9 shows sample debug apple events output when a nondiscovery-enabled router is brought
up on an AppleTalk internetwork that is in compatibility mode (set up to accommodate extended as
well as nonextended AppleTalk) and the router has violated internetwork compatibility.
Figure 2-9 Sample Debug Apple Events Output Showing Compatibility Conflict
Ethernet1: AT: Resetting interface address filters
%AT-5-INTRESTART: Ethernet1: AppleTalk port restarting; protocol restarted
Ethernet1: AppleTalk state changed; unknown -> restarting
Ethernet1: AppleTalk state changed; restarting -> probing
%AT-6-ADDRUSED: Ethernet1: AppleTalk node up; using address 4165.204
Ethernet1: AppleTalk state changed; probing -> verifying
Ethernet1: AppleTalk state changed; verifying -> operational
%AT-6-ONLYROUTER: Ethernet1: AppleTalk port enabled; no neighbors found
S
2
5
4
3
Indicates a nondiscovery-
enabled router with no
other router on the wire
E0: AT: Resetting interface address filters
%AT-5-INTRESTART: E0: AppleTalk port restarting; protocol restarted
E0: AppleTalk state changed; restarting -> probing
%AT-6-ADDRUSED: E0: AppleTalk node up; using address 41.19
E0: AppleTalk state changed; probing -> verifying
%AT-3-ZONEDISAGREES: E0: AT port disabled; zone list incompatible with 41.19
AT: Config error for E0, primary zone invalid
E0: AppleTalk state changed; verifying -> config mismatch S
2
5
4
5
Indicates
configuration
mismatch
debug apple events
The three configuration command lines that follow indicate the part of the routers configuration that
caused the configuration mismatch shown in Figure 2-9:
lestat(config)#int e 0
lestat(config-if)#apple cab 41-41
lestat(config-if)#apple zone Marketign
The router shown in Figure 2-9 had been configured with a cable range of 41-41 instead of 40-40,
which would have been accurate. Additionally, the zone name was configured incorrectly; it should
have been Marketing, rather than being misspelled as Marketign.
Debug Commands 2-17
debug apple nbp
debug apple nbp
Use the debug apple nbp EXEC command to display debugging output from the Name Binding
Protocol (NBP) routines. The no form of this command disables debugging output.
debug apple nbp [type number]
no debug apple nbp [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
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 the node in question to determine
where the problem lies.
Note Because the debug apple nbp command can generate many messages, use it only when the
routers CPU utilization is less than 50 percent.
debug apple nbp
Sample Display
Figure 2-10 shows sample debug apple nbp output.
Figure 2-10 Sample Debug Apple NBP Output
router# debug apple nbp
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
AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77
AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW Lab
AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW Lab
AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW Lab
AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW Lab
The first three lines in Figure 2-10 describe an NBP lookup request:
Table 2-2 describes the fields in the first line of output shown in Figure 2-10.
Table 2-2 Debug Apple NBP Field DescriptionsPart 1
Table 2-3 describes the fields in the second line of output shown in Figure 2-10.
Field Description
AT: NBP Indicates that this message describes an AppleTalk NBP packet.
ctrl = LkUp Identifies the type of NBP packet. Possible values include
LkUpNBP lookup request.
LkUp-ReplyNBP lookup reply.
ntuples = 1 Indicates the number of name-address pairs in the lookup request packet.
Range: 1-31 tuples.
id = 77 Identifies an NBP lookup request value.
Debug Commands 2-19
debug apple nbp
Table 2-3 Debug Apple NBP Field DescriptionsPart 2
The third line in Figure 2-10 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.
Because 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 2-10 show the routers 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 routers 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.
Field Description
AT: Indicates that this message describes an AppleTalk packet.
4160.19 Indicates the network address of the requester.
skt 2 Indicates the internet socket address of the requester. The responder will
send the NBP lookup reply to this socket address.
enum 0 Indicates the enumerator field. Used to identify multiple names
registered on a single socket. Each tuple is assigned its own enumerator,
incrementing from 0 for the first tuple.
name: =:ciscoRouter@Low End
SW Lab
Indicates the entity name for which a network address has been
requested. The AppleTalk entity name includes three components:
Object (in this case, a wildcard character (=), indicating that the
requester is requesting name-address pairs for all objects of the specified
type in the specified zone)
Type (in this case, ciscoRouter)
Zone (in this case, Low End SW Lab)
debug apple packet
debug apple packet
Use the debug apple packet EXEC command to display per-packet debugging output. The output
reports information online when a packet is received or a transmit is attempted. The no form of this
command disables debugging output.
debug apple packet [type number]
no debug apple packet [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
With this command, you can monitor the types of packets being slow switched. It displays at least
one line of debugging output per AppleTalk packet processed.
When invoked in conjunction with the debug apple routing, debug apple zip, and debug apple
nbp commands, the debug apple packet command adds protocol processing information in
addition to generic packet details. It also reports successful completion or failure information.
When invoked in conjunction with the debug apple errors command, the debug apple packet
command reports packet-level problems, such as those concerning encapsulation.
Note Because the debug apple packet command can generate many messages, use it only when
the routers CPU utilization is less than 50 percent.
Sample Display
Figure 2-11 shows sample debug apple packet output.
Figure 2-11 Sample Debug Apple Packet Output
router# debug apple packet
Ether0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000
AT: src=Ethernet0:4160.47, dst=4160-4160, size=10, 2 rtes, RTMP pkt sent
AT: ZIP Extended reply rcvd from 4160.19
AT: ZIP Extended reply rcvd from 4160.19
Table 2-4 describes the fields in the first line of output shown in Figure 2-11.
Debug Commands 2-21
debug apple packet
Table 2-4 Debug Apple Packet Field DescriptionsPart 1
Table 2-5 describes the fields in the second line of output shown in Figure 2-11.
Table 2-5 Debug Apple Packet Field DescriptionsPart 2
The third line in Figure 2-11 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.
Field Description
Ether0: Name of the interface through which the router received the
packet
AppleTalk packet Indication that this is an AppleTalk packet
enctype SNAP Encapsulation type for the packet
size 60 Size of the packet (in bytes)
encaps000000000000000000000000 Encapsulation
Field Description
AT: Indication that this is an AppleTalk packet
src = Ethernet0:4160.47 Name of the interface sending the packet and its AppleTalk address
dst = 4160-4160 Cable range of the packets destination
size = 10 Size of the packet (in bytes)
2 rtes Indication that two routes in the routing table link these two addresses
RTMP pkt sent The type of packet sent
debug apple remap
debug apple remap
Use the debug apple remap EXEC command to enable debugging of the AppleTalk remap
activities. The no form of this command disables debugging output.
debug apple remap
no debug apple remap
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use the debug apple remap command with the debug apple domain command to observe activity
between domains and subdomains. Messages from debug apple remap are displayed when a
particular remapping function occurs, such as creating remaps or deleting remaps.
Sample Display
Figure 2-12 shows sample debug apple remap output intermixed with output from the debug apple
domain command; the two commands show related events.
Figure 2-12 Sample Debug Output
router# debug apple remap
router# debug apple domain
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1
AT-REMAP: ReshuffleRemapList for subdomain 1
AT-REMAP: Could not find a remap for cable 3000-3001
AT-DOMAIN: atdomain_DisablePort for Tunnel0
AT-DOMAIN: Disabling interface Ethernet1
AT-DOMAIN: atdomain_DisablePort for Ethernet1
AT-REMAP: Remap for net 70 inbound subdomain 1 has been deleted
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1 Remaped Net 10000
AT-REMAP: Remap for net 50 outbound subdomain 1 has been deleted
Debug Commands 2-23
debug apple remap
Related Command
debug apple domain
debug apple routing
debug apple routing
Use the debug apple routing EXEC command to enable debugging output from the Routing Table
Maintenance Protocol (RTMP) routines. The no form of this command disables debugging output.
debug apple routing [type number]
no debug apple routing [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
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.
Note Because the debug apple routing command can generate many messages, use it only when
router CPU utilization is less than 50 percent.
Sample Display
Figure 2-13 shows sample debug apple routing output.
Figure 2-13 Sample Debug Apple Routing Output
router# debug apple routing
AT: src=Ethernet1:41069.25, dst=41069, size=427, 96 rtes, RTMP pkt sent
AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)
AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0)
Explanations for representative lines of the debug apple routing output in Figure 2-13 follow.
Table 2-6 describes the fields in the first line of sample debug apple routing output.
Debug Commands 2-25
debug apple routing
Table 2-6 Debug Apple Routing Field DescriptionsPart 1
The following two messages indicate that the ager has started and finished the aging process for the
routing table and that this table contains 97 entries.
AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)
Table 2-7 describes the fields in the following line of debug apple routing output.
Table 2-7 Debug Apple Routing Field DescriptionsPart 2
Field Description
AT: Indicates that this is AppleTalk debugging output
src = Ethernet0:4160.41 Indicates the source router interface and network address for the RTMP
update packet
dst = 4160-4160 Indicates the destination network address for the RTMP update packet
size = 19 Shows the size of this RTMP packet (in bytes)
2 rtes Indicates that this RTMP update packet includes information on two
routes
RTMP pkt sent Indicates that this type of message describes an RTMP update packet
that the router has sent (rather than one that it has received)
Field Description
AT: Indicates that this is AppleTalk debugging output
RTMP from 4160.19 Indicates the source address of the RTMP update the router received
new 0 Shows the number of routes in this RTMP update packet that the router did not
already know about
old 94 Shows the number of routes in this RTMP update packet that the router
already knew about
bad 0 Shows the number of routes the other router indicates have gone bad
ign 0 Shows the number of routes the other router ignores
dwn 0 Shows the number of poisoned tuples included in this packet
debug apple zip
debug apple zip
Use the debug apple zip EXEC command to display debugging output from the Zone Information
Protocol (ZIP) routines. The no form of this command disables debugging output.
debug apple zip [type number]
no debug apple zip [type number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command reports significant events such as the discovery of new zones and zone list queries. It
generates information similar to that generated by debug apple routing, but generates it for ZIP
packets instead of RTMP packets.
You can use he debug apple zip command 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.
Sample Display
Figure 2-14 shows sample debug apple zip output.
Figure 2-14 Sample Debug Apple ZIP Output
router# debug apple zip
AT: Recvd ZIP cmd 6 from 4160.19-6
AT: 3 query packets sent to neighbor 4160.19
AT: 1 zones for 31902, ZIP XReply, src 4160.19
AT: net 31902, zonelen 10, name US-Florida
Explanations of the lines of output shown in Figure 2-14 follow.
Debug Commands 2-27
debug apple zip
The first line indicates that the router has received an RTMP update that includes a new network
number and is now requesting zone information:
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
The third line indicates that the router responds with 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 indicates 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-Florida,
and the zone length of that zone name is 10:
AT: net 31902, zonelen 10, name US-Florida
debug appn all
debug appn all
Use the debug appn all command to turn on all possible debugging messages for Advanced
Peer-to-Peer Networking (APPN). The no form of this command disables debugging output.
debug appn all
no debug appn all
Syntax Description
Note Refer to the other forms of the debug appn command to enable specific debug output
selectively.
Command Mode
EXEC
Usage Guidelines
This command shows all APPN events. Use other forms of the debug appn command to display
specific types of events.
Note Because the debug appn all command can generate many messages and alter timing in the
network node, use it only when instructed by authorized support personnel.
Caution Debugging output takes priority over other network traffic. The debug appn all command
generates more output than any other debug appn command and can alter timing in the network
node. This command can severely diminish router performance or even render it unusable. In
virtually all cases, it is best to use specific debug appn commands.
Related Commands
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trs
Debug Commands 2-29
debug appn cs
debug appn cs
Use the debug appn cs command to display APPN Configuration Services (CS) component activity.
debug appn cs
no debug appn cs
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Configuration Services (CS) component is responsible for defining link stations, ports, and
connection networks. It is responsible for the activation and deactivation of ports and link stations
and handles status queries for these resources.
Sample Display
Figure 2-15 shows sample debug appn cs output. In this example a link station is being stopped.
Figure 2-15 Sample Debug APPN CS Output
router# debug appn cs
Turned on event 008000FF
router# appn stop link PATTY
APPN: ----- CS ----- Deq STOP_LS message
APPN: ----- CS ----- FSM LS: 75 17 5 8
APPN: ----- CS ----- Sending DEACTIVATE_AS - station PATTY
APPN: ----- CS ----- deactivate_as_p->ips_header.lpid = A80A60
APPN: ----- CS ----- deactivate_as_p->ips_header.lpid = A80A60
APPN: ----- CS ----- Sending DESTROY_TG to PC - station PATTY - lpid=A80A60
APPN: ----- CS ----- Deq DESTROY_TG - station PATTY
APPN: ----- CS ----- FSM LS: 22 27 8 0
APPN: ----- CS ----- Sending TG update for LS PATTY to TRS
APPN: ----- CS ----- ENTERING XID_PROCESSING: 4
%APPN-6-APPNSENDMSG: Link Station PATTY stopped
debug appn cs
Table 2-8 shows describes the fields and messages shown in Figure 2-15.
Table 2-8 Debug APPN CS Field Descriptions
Related Commands
debug appn all
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trs
Field Description
APPN APPN debugging output.
CS Configuration Services component output.
Deq CS received a message from another component.
FSM LS The link station finite state machine is being referenced.
Sending CS is sending a message to another component.
Debug Commands 2-31
debug appn ds
debug appn ds
Use the debug appn ds command to to display debugging information on APPN Directory Services
(DS) component activity. The no form of this command disables debugging output.
debug appn ds
no debug appn ds
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Directory Services (DS) component manages searches for resources in the APPN network. DS
is also responsible for registration of resources within the network.
Sample Display
Figure 2-16 shows sample debug appn ds output. In this example a search has been received.
Figure 2-16 Sample Debug APPN DS Output
router# debug appn ds
APPN: NEWDS: LS: search from: NETA.PATTY
APPN: NEWDS: pcid: DD3321E8B5667111
APPN: NEWDS: Invoking FSM NNSolu
APPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 0 col: 0 inp: 80200000
APPN: NEWDS: LSfsm_parent: 00A89940 row: 0 col: 0 inp: 80000000
APPN: NEWDS: Rcvd a LMRQ
APPN: NEWDS: LSfsm_child: 00A89BE8 row: 0 col: 0 inp: 80000080
APPN: NEWDS: PQenq REQUEST_ROUTE(RQ) to TRS
APPN: NEWDS: LSfsm_child: 00A8A1C0 row: 1 col: 0 inp: 80000008
APPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 5 col: 1 inp: 80C04000
APPN: NEWDS: Rcvd a LMRY
APPN: NEWDS: send locate to node: NETA.PATTY
Table 2-9 provides explanations for fields in the debug appn ds output shown in Figure 2-16.
debug appn ds
Table 2-9 Debug APPN DS Field Descriptions
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trs
Field Description
NEWDS Directory Services component output.
search from A locate was received from NETA.PATTY.
LSfsm_ The Locate Search finite state machine is being referenced.
PQenq A message was sent to another component.
Rcvd A message was received from another component.
send locate A locate will be sent to NETA.PATTY.
Debug Commands 2-33
debug appn ms
debug appn ms
Use the debug appn ms command to display to display debugging information on APPN
Management Services (MS) component activity. The no form of this command disables debugging
output.
debug appn ms
no debug appn ms
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Management Services (MS) component is responsible for generating, sending, and forwarding
network management information in the form of traps and alerts to a network management focal
point, such as Netview, in the APPN network.
Sample Display
Figure 2-17 shows sample debug appn ms output. In this example an error occurred that caused an
alert to be generated.
Figure 2-17 Sample Debug APPN MS Output
router# debug appn ms
APPN: ----- MSS00 ---- Deq ALERT_MSU msg
APPN: --- MSP70 --- ALERT MV FROM APPN WITH VALID LGTH
APPN: --- MSCPL --- Find Active FP
APPN: --- MSP30 --- Entering Build MS Transport
APPN: --- MSP31 --- Entering Building Routing Info.
APPN: --- MSP34 --- Entering Build GDS
APPN: --- MSP32 --- Entering Building UOW correlator
APPN: --- MSP34 --- Entering Build GDS
APPN: --- MSP30 --- Building GDS 0x1310
APPN: --- MSP30 --- Building MS Transport
APPN: --- MSP72 --- ACTIVE FP NOT FOUND, SAVE ONLY
APPN: --- MSUTL --- UOW <= 60, ALL COPIED in extract_uow
APPN: --- MSCAT --- by enq_cached_ms QUEUE SIZE OF QUEUE after enq 4
Table 2-10 describes fields in the debug appn ms output shown in Figure 2-17.
Table 2-10 Debug APPN MS Output Field Descriptions
Field Description
APPN Indicates that this is APPN debugging output.
MSP Indicates that this is MS component output.
debug appn ms
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trs
Debug Commands 2-35
debug appn nof
debug appn nof
Use the debug appn nof command to display debugging information on APPN Node Operator
Facility (NOF) component activity. The no form of this command disables debugging output.
debug appn nof
no debug appn nof
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Node Operator Facility (NOF) component is responsible for processing commands entered by
the user such as start, stop, show, and configuration commmands. NOF forwards these commands to
the proper component and wait for the response.
Sample Display
Figure 2-18 shows sample debug appn nof output. In this example an APPN connection network is
being defined.
Figure 2-18 Sample Debug APPN NOF Output
router# debug appn nof
router# config term
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#appn connection-network NETA.CISCO
router(config-appn-cn)#port TR0
router(config-appn-cn)#complete
router(config)#
APPN: ----- NOF ----- Define Connection Network Verb Received
APPN: ----- NOF ----- send define_cn_t ips to cs
APPN: ----- NOF ----- waiting for define_cn rsp from cs
router(config)#
Table 2-11 describes fields in the debug appn nof output shown in Figure 2-18.
debug appn nof
Table 2-11 Debug APPN NOF Field Descriptions
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trs
Field Description
NOF NOF component output.
Received A configuration command was entered.
send A message was sent to CS.
waiting A response was expected from CS.
Debug Commands 2-37
debug appn pc
debug appn pc
Use the debug appn pc command to display debugging information on APPN Path Control (PC)
component activity. The no form of this command disables debugging output.
debug appn pc
no debug appn pc
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Path Control (PC) component is responsible for passing Message Units (MUs) between the Data
Link Control (DLC) layer and other APPN components. PC implements transmission priority by
passing higher priority MUs to the DLC before lower priority MUs.
Sample Display
Figure 2-19 shows sample debug appn pc output. In this example a MU is received from the
network.
Figure 2-19 Sample Debug APPN PC Output
router# debug appn pc
APPN: ----- PC ----- PC Deq REMOTE msg variant_name 2251
APPN: --PC-- mu received to PC lpid: A80AEC
APPN: --PC-- mu received from p_cep_id: 67C6F8
APPN: ----- PC ----- PC Deq LSA_IPS from DLC
APPN: --PCX dequeued a DATA.IND
APPN: --- PC processing DL_DATA.ind
APPN: --PC-- mu_error_checker with no error, calling frr
APPN: --PC-- calling frr for packet received on LFSID: 1 2 3
APPN: ----- PC ----- PC is sending MU to SC A90396
APPN: ----- SC ----- send mu: A90396, rpc: 0, nws: 7, rh.b1: 90
APPN: SC: Send mu.snf: 8, th.b0: 2E, rh.b1: 90, dcf: 8
Table 2-12 describes fields in the debug appn pc output shown in Figure 2-19.
debug appn pc
Table 2-12 Debug APPN PC Field Descriptions
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trs
Field Description
PC PC component output.
Deq REMOTE A message was received from the network.
mu received The message is a MU.
DATA.IND The MU contains data.
sending MU The MU is session traffic for an ISR session. The MU is forwarded to the
Session Connector component for routing.
Debug Commands 2-39
debug appn ps
debug appn ps
Use the debug appn ps command to display debugging information on APPN Presentation Services
(PS) component activity. The no form of this command disables debugging output.
debug appn ps
no debug appn ps
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Presentation Services (PS) component is responsible for managing the Transaction Programs
(TPs) used by APPN. TPs are used for sending and receiving searches, receiving resource
registration, and sending and receiving topology updates.
Sample Display
Figure 2-20 shows sample debug appn ps output. In this example a CP capabilities exchange is in
progress.
Figure 2-20 Sample Debug APPN PS Output
router# debug appn ps
APPN: ---- CCA --- CP_CAPABILITIES_TP has started
APPN: ---- CCA --- About to wait for Partner to send CP_CAP
APPN: ---- CCA --- Partner LU name: NETA.PATTY
APPN: ---- CCA --- Mode Name: CPSVCMG
APPN: ---- CCA --- CGID: 78
APPN: ---- CCA --- About to send cp_cp_session_act to SS
APPN: ---- CCA --- Waiting for cp_cp_session_act_rsp from SS
APPN: ---- CCA --- Received cp_cp_session_act_rsp from SS
APPN: ---- CCA --- About to send CP_CAP to partner
APPN: ---- CCA --- Send to partner completed with rc=0, 0
APPN: ---- RCA --- Allocating conversation
APPN: ---- RCA --- Sending CP_CAPABILITIES
APPN: ---- RCA --- Getting conversation attributes
APPN: ---- RCA --- Waiting for partner to send CP_CAPABILITIES
APPN: ---- RCA --- Normal processing complete with cgid = 82
APPN: ---- RCA --- Deallocating CP_Capabilities conversation
Table 2-13 describes fields in the debug appn ps output shown in Figure 2-20.
debug appn ps
Table 2-13 Debug APPN PS Field Descriptions
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn scm
debug appn ss
debug appn trs
Field Description
CCA CP Capabilities TP output.
RCA Receive CP Capabilities TP output.
Debug Commands 2-41
debug appn scm
debug appn scm
Use the debug appn scm command to display debugging information on APPN Session Connector
Manager (SCM) component activity. The no form of this command disables debugging output.
debug appn scm
no debug appn scm
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Session Connector Manager (SCM) component is responsible for the activation and deactivation
the local resources that route an intermediate session through the router.
Sample Display
Figure 2-21 shows sample debug appn scm output. In this example an intermediate session traffic
is being routed.
Figure 2-21 Sample Debug APPN SCM Output
router# debug appn scm
router#
APPN: ----- SCM ----- SCM Deq a MU
APPN: ----- SCM ----- SCM send ISR_INIT to SSI
APPN: ----- SCM ----- (i05) Enter compare_fqpcid()
APPN: ----- SCM ----- Adding new session_info table entry. addr=A93160
APPN: ----- SCM ----- SCM Deq ISR_CINIT message
APPN: ----- SCM ----- SCM sends ASSIGN_LFSID to ASM
APPN: ----- SCM ----- SCM Rcvd sync ASSIGN_LFSID from ASM
APPN: ----- SCM ----- SCM PQenq a MU to ASM
APPN: ----- SCM ----- SCM Deq a MU
APPN: ----- SCM ----- SCM PQenq BIND rsp to ASM
Table 2-14 describes fields in the debug appn ps output shown in Figure 2-21.
Table 2-14 Debug APPN SCM Field Descriptions
Field Description
SCM SCM component output.
debug appn scm
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn ss
debug appn trs
Debug Commands 2-43
debug appn ss
debug appn ss
Use the debug appn ss command to display session services events. The no form of this command
disables debugging output.
debug appn ss
no debug appn ss
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Session Services (SS) component generates unique session identifiers, activates and deactivates
control point-to-control point (CP-CP) sessions, and assists LUs in initiating and activating LU-LU
sessions.
Sample Display
Figure 2-22 shows sample debug appn ss output. In this example CP-CP sessions between the
router and another node are being activated.
Figure 2-22 Sample Debug APPN SS Output
router# debug appn ss
APPN: ----- SS ----- Deq ADJACENT_CP_CONTACTED message
APPN: ----- SS ----- Deq SESSST_SIGNAL message
APPN: ----- SS ----- Deq CP_CP_SESSION_ACT message
APPN: Sending ADJACENT_NN_1015 to SCM, adj_node_p=A6B980,cp_name=NETA.PATTY
APPN: ----- SS ----- Sending REQUEST_LAST_FRSN message to TRS
APPN: ----- SS ----- Receiving REQUEST_LAST_FRSN_RSP from TRS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to DS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to MS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to TRS
APPN: ----- SS ----- Sending CP_CP_SESSION_ACT_RSP message to CCA TP
APPN: ----- SS ----- Sending PENDING_ACTIVE CP_STATUS CONWINNER message to DS
APPN: ----- SS ----- Sending REQUEST_LAST_FRSN message to TRS
APPN: ----- SS ----- Receiving REQUEST_LAST_FRSN_RSP from TRS
APPN: ----- SS ----- Sending ACT_CP_CP_SESSION message to RCA TP
APPN: ----- SS ----- Deq ASSIGN_PCID message
APPN: ----- SS ----- Sending ASSIGN_PCID_RSP message to someone
APPN: ----- SS ----- Deq INIT_SIGNAL message
APPN: ----- SS ----- Sending REQUEST_COS_TPF_VECTOR message to TRS
APPN: ----- SS ----- Receiving an REQUEST_COS_TPF_VECTOR_RSP from TRS
APPN: ----- SS ----- Sending REQUEST_SINGLE_HOP_ROUTE message to TRS
APPN: ----- SS ----- Receiving an REQUEST_SINGLE_HOP_ROUTE_RSP from TRS
APPN: ----- SS ----- Sending ACTIVATE_ROUTE message to CS
APPN: ----- SS ----- Deq ACTIVATE_ROUTE_RSP message
APPN: ----- SS ----- Sending CINIT_SIGNAL message to SM
APPN: ----- SS ----- Deq ACT_CP_CP_SESSION_RSP message
debug appn ss
APPN: -- SS -- SS ssp00, act_cp_cp_session_rsp received, sense_code=0, cgid=5C,
ips@=A93790
APPN: Sending ADJACENT_NN_1015 to SCM, adj_node_p=A6B980,cp_name=18s
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to DS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to MS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to TRS
Table 2-15 describes fields in the debug appn ssoutput shown in Figure 2-22.
Table 2-15 Debug APPN SS Field Descriptions
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn trs
Field Description
SS SS component output.
Debug Commands 2-45
debug appn trs
debug appn trs
Use the debug appn trs command to display debugging information on APPN Topology and
Routing Services (TRS) component activity. The no form of this command disables debugging
output.
debug appn trs
no debug appn trs
Syntax Description
Command Mode
EXEC
Usage Guidelines
The Topology and Routing Services (TRS) component is responsible for creating and maintaining
the topology database, creating and maintaining the class of service database, and computing and
caching optimal routes through the network.
Sample Display
Figure 2-23 shows sample debug appn trs output.
Figure 2-23 Sample Debug APPN TRS Output
router# debug appn trs
APPN: ----- TRS ----- Received a QUERY_CPNAME
APPN: ----- TRS ----- Received a REQUEST_ROUTE
APPN: ----- TRS ----- check_node node_name=NETA.LISA
APPN: ----- TRS ----- check_node node_index=0
APPN: ----- TRS ----- check_node node_weight=60
APPN: ----- TRS ----- add index 484 to origin description list
APPN: ----- TRS ----- add index 0 to dest description list
APPN: ----- TRS ----- origin tg_vector is NULL
APPN: ----- TRS ----- weight_to_origin = 0
APPN: ----- TRS ----- weight_to_dest = 0
APPN: ----- TRS ----- u_b_s_f weight = 30
APPN: ----- TRS ----- u_b_s_f prev_weight = 2147483647
APPN: ----- TRS ----- u_b_s_f origin_index = 484
APPN: ----- TRS ----- u_b_s_f dest_index = 0
APPN: ----- TRS ----- b_r_s_f weight = 30
APPN: ----- TRS ----- b_r_s_f origin_index = 484
APPN: ----- TRS ----- b_r_s_f dest_index = 0
APPN: ----- TRS ----- Received a REQUEST_ROUTE
APPN: ----- TRS ----- check_node node_name=NETA.LISA
APPN: ----- TRS ----- check_node node_name=NETA.BART
APPN: ----- TRS ----- add index 484 to origin description list
debug appn trs
APPN: ----- TRS ----- add index 0 to dest description list
APPN: ----- TRS ----- origin_tg_weight to non-VN=30
APPN: ----- TRS ----- origin_node_weight to non-VN=60
APPN: ----- TRS ----- weight_to_origin = 90
APPN: ----- TRS ----- weight_to_dest = 0
APPN: ----- TRS ----- u_b_s_f weight = 120
APPN: ----- TRS ----- u_b_s_f prev_weight = 2147483647
APPN: ----- TRS ----- u_b_s_f origin_index = 484
APPN: ----- TRS ----- u_b_s_f dest_index = 0
APPN: ----- TRS ----- b_r_s_f weight = 120
APPN: ----- TRS ----- b_r_s_f origin_index = 484
APPN: ----- TRS ----- b_r_s_f dest_index = 0
Table 2-16 describes fields in the debug appn trs output shown in Figure 2-23.
Table 2-16 Debug APPN TRS Field Descriptions
Related Commands
debug appn all
debug appn cs
debug appn dlur
debug appn ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
Field Description
TRS TRS component output.
Debug Commands 2-47
debug arap
debug arap
Use the debug arap command to display AppleTalk Remote Access Protocol (ARAP) events. The
no form of this command disables debugging output.
debug arap [internal]
no debug arap
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use the debug arap command with the debug callback command on access servers to debug dial-in
and callback events.
Sample Display
Figure 2-24 shows sample debug arap output.
Figure 2-24 Sample Debug ARAP Output
router# debug arap internal
ARAP: ---------- SRVRVERSION ----------
ARAP: ---------- ACKing 0 ----------
ARAP: ---------- AUTH_CHALLENGE ----------
arapsec_local_account setting up callback
ARAP: ---------- ACKing 1 ----------
ARAP: ---------- AUTH_RESPONSE ----------
arap_startup initiating callback ARAP 2.0
ARAP: ---------- CALLBACK ----------
TTY7 Callback process initiated, user: dialback dialstring 40
TTY7 Callback forced wait = 4 seconds
TTY7 ARAP Callback Successful - await exec/autoselect pickup
TTY7: Callback in effect
ARAP: ---------- STARTINFOFROMSERVER ----------
ARAP: ---------- ACKing 0 ----------
ARAP: ---------- ZONELISTINFO ----------
The displayed information self-explanatory.
Related Command
debug callback
internal (Optional) Limits display to internal ARAP events.
debug arp
debug arp
Use the debug arp EXEC command to display information on Address Resolution Protocol (ARP)
transactions. The no form of this command disables debugging output.
debug arp
no debug arp
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use this command when some nodes on a TCP/IP network are responding, but others are not. It
shows whether the router is sending ARPs and whether it is receiving ARPs.
Sample Display
Figure 2-25 shows sample debug arp output.
Figure 2-25 Sample Debug ARP Output
router# debug arp
IP ARP: sent req src 131.108.22.7 0000.0c01.e117, dst 131.108.22.96 0000.0000.0000
IP ARP: rcvd rep src 131.108.22.96 0800.2010.b908, dst 131.108.22.7
IP ARP: rcvd req src 131.108.6.10 0000.0c00.6fa2, dst 131.108.6.62
IP ARP: rep filtered src 131.108.22.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffff
IP ARP: rep filtered src 131.108.9.7 0000.0c00.6b31, dst 131.108.22.7 0800.2010.b908
In Figure 2-25, 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
Debug Commands 2-49
debug arp
The fourth line indicates that another host on the network attempted to send the router an ARP reply
for its own address. The router ignores meaningless replies. Usually, meaningless replies happen if
someone is running a bridge in parallel with the router and is allowing ARP to be bridged. This
condition 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.7, 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 atm errors
debug atm errors
Use the debug atm errors EXEC command to display Asynchronous Transfer Mode (ATM) errors.
debug atm errors
no debug atm errors
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-26 shows sample debug atm errors output.
Figure 2-26 Sample Debug ATM Errors Output
router# debug atm errors
ATM(ATM2/0): Encapsulation error, link=7, host=836CA86D.
ATM(ATM4/0): VCD#7 failed to echo OAM. 4 tries
The first line of output in Figure 2-26 indicates that a packet was routed to the ATM interface, but
no static map was set up to route that packet to the proper virtual circuit.
The second line of output shows that an OAM F5 (virtual circuit) cell error occurred.
Debug Commands 2-51
debug atm events
debug atm events
Use the debug atm events EXEC command to display ATM events. The no form of this command
debug atm events
no debug atm events
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command displays ATM events that occur on the ATM interface processor and is useful for
diagnosing problems in an ATM network. It provides an overall picture of the stability of the
network. In a stable network, the debug atm events command does not return any information. If
the command generates numerous messages, the messages can indicate the possible source of
problems.
When configuring or making changes to a router or interface for ATM, enable debug atm events.
Doing so alerts you to the progress of the changes or to any errors that might result. Also use this
command periodically when you suspect network problems.
Sample Display
Figure 2-27 shows sample debug atm events output.
Figure 2-27 Sample Debug ATM Events Output
router# debug atm events
ATM events debugging is on
RESET(ATM4/0): PLIM type is 1, Rate is 100Mbps
aip_disable(ATM4/0): state=1
config(ATM4/0)
aip_love_note(ATM4/0): asr=0x201
aip_enable(ATM4/0)
aip_enable(ATM4/0): restarting VCs: 7
aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1
debug atm events
Table 2-17 describes significant fields in the output shown in Figure 2-27.
Table 2-17 Debug ATM Events Field Descriptions
The following line indicates that the ATM Interface Processor (AIP) was reset. The PLIM TYPE
detected was 1, so the maximum rate is set to 100 Mbps.
RESET(ATM4/0): PLIM type is 1, Rate is 100Mbps
The following line indicates that the ATM Interface Processor (AIP) was given a shutdown
command, but the current configuration indicates that the AIP should be up:
aip_disable(ATM4/0): state=1
The following line indicates that a configuration command has been completed by the AIP:
The following line indicates that the AIP was given a no shutdown command to take it out of
shutdown:
aip_enable(ATM4/0)
The following line indicates that the AIP detected a carrier state change. It does not indicate that the
carrier is down or up, only that it has changed:
The following line of output indicates that the AIP enable function is restarting all PVCs
automatically:
aip_enable(ATM4/0): restarting VCs: 7
Field Description
PLIM type Indicates the interface rate in Mbps. Possible values are
1 = TAXI(4B5B) 100 Mbps
2 = SONET 155 Mbps
3 = E3 34 Mbps
state Indicates current state of the AIP. Possible values are
1 = An ENABLE will be issued soon
0 = The AIP will remain shut down
asr Defines a bitmask, which indicates actions or completions to commands. Valid
bitmask values are
0x0800 = AIP crashed, reload may be required.
0x0400 = AIP detected a carrier state change.
0x0n00 = Command completion status. Command completion status codes are
n = 8 Invalid PLIM detected
n = 4 Command failed
n = 2 Command completed successfully
n = 1 CONFIG request failed
n = 0 Invalid value
Debug Commands 2-53
debug atm events
The following lines of output indicate that PVC 1 was set up and a successful completion code was
returned:
debug atm oam
debug atm oam
Use the debug atm oam command to display ATM operation and maintnenance (OAM) events. The
debug atm oam
no debug atm oam
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-28 shows sample debug atm oam output.
Figure 2-28 Sample Debug ATM OAM Output
router# debug atm oam
ATM4/0(O): VCD:0x0 DM:0x300 *OAM Cell* Length:0x39
0000 0300 0070 007A 0018 0100 0000 05FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF FF6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A00 0000
Table 2-18 describes the output fields shown in Figure 2-28.
Table 2-18 Debug ATM OAM Field Descriptions
Field Description
0000 VCD Special OAM indicator
0300 Descriptor MODE bits for the AIP
0 GFC (4 bits)
07 VPI (8 bits)
0007 VCI (16 bits)
A Payload type field(PTI)(4 bits)
00 Header Error Correction(8 bits)
1 OAM Fault mgmt. cell(4 bits)
8 OAM LOOPBACK indicator (4 bits)
01 Loopback indicator value, always 1(8 bits)
00000005 Loopback unique ID, sequence number (32 bits)
FF6A Fs and 6A required in the remaining ATM cell, per UNI3.0
Debug Commands 2-55
debug atm packet
debug atm packet
Use the debug atm packet EXEC command to display per-packet debugging output. The output
reports information online when a packet is received or a transmit is attempted. The no form of this
debug atm packet
no debug atm packet
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug atm packet command displays all process-level ATM packets for both outbound and
inbound packets. This command is useful for determining whether packets are being received and
transmitted correctly.
For transmitted packets, the information is displayed only after the protocol data unit (PDU) is
entirely encapsulated and a next hop virtual circuit (VC) is found. If information is not displayed,
the address translation probably failed during encapsulation. When a next hop VC is found, the
packet is displayed exactly as it will be presented on the wire. Having a display indicates the packets
are properly encapsulated for transmission.
For received packets, information is displayed for all incoming frames. The display can show
whether the transmitting station properly encapsulates the frames. Because all incoming frames are
displayed, this information is useful when performing back-to-back testing and corrupted frames
cannot be dropped by an intermediary ATM switch.
The debug atm packet command also displays the initial bytes of the actual PDU in hexadecimal.
This information can be decoded only by qualified support or engineering personnel.
Note Because the debug atm packet command generates a significant amount of output for every
packet processed, use it only when traffic on the network is low, so other activity on the system is
not adversely affected.
Sample Display
Figure 2-29 shows sample debug atm packet output.
Figure 2-29 Sample Debug ATM Packet Output
router# debug atm packets
ATM packets debugging is on
router#
ATM2/0(O): VCD: 0x1,DM: 1C00, MUX, ETYPE: 0800,Length: 32
4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000
A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
debug atm packet
Table 2-19 describes significant fields shown in Figure 2-29.
Table 2-19 Debug ATM Packet Field Descriptions
The following two lines of output are the binary data, which are the contents of the protocol PDU
before encapsulation at the ATM:
4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000
A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
Field Description
ATM2/0 Indicates the interface that generated this packet.
(O) Indicates an output packet. (I) would mean receive packet.
VCD: 0xn Indicates the virtual circuit associated with this packet, where n is some value.
DM: 0xnnnn Indicates the descriptor mode bits on output only, where nnnn is a hexadecimal
value.
ETYPE: n Shows the Ethernet type for this packet.
Length: n Shows the total length of the packet including the ATM header(s).
Debug Commands 2-57
debug bri
debug bri
Use the debug bri EXEC command to display debugging information on Integrated Services Digital
Networks (ISDN) Basic Rate Interface (BRI) routing activity. The no form of this command disables
debugging output.
debug bri
no debug bri
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug bri command indicates whether the ISDN code is enabling and disabling the B-channels
when attempting an outgoing call. This command is available for the low-end router products that
have a multi-BRI network interface module installed.
Note Because the debug bri command generates a significant amount of output, use it only when
traffic on the IP network is low, so other activity on the system is not adversely affected.
Sample Display
Figure 2-30 shows sample debug bri output.
Figure 2-30 Sample Debug BRI Packets Output
Router# debug bri
Basic Rate network interface debugging is on
BRI: write_sid: wrote 1B for subunit 0, slot 1.
BRI: write_sid: wrote 15 for subunit 0, slot 1.
BRI: Starting Power Up timer for unit = 0.
BRI: Starting T3 timer after expiry of PUP timeout for unit = 0, current state is F4.
BRI: write_sid: wrote FF for subunit 0, slot 1.
BRI: Activation for unit = 0, current state is F7.
BRI: enable channel B1
debug bri
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up
%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up.!!!
BRI: disable channel B1
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down
%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed state to down
Explanations for individual lines of output from Figure 2-30 follow.
The following line indicates that an internal command was written to the interface controller. The
subunit identifies the first interface in the slot:
The following line indicates that the power-up timer was started for the named unit:
BRI: Starting Power Up timer for unit = 0.
The following lines indicate that the channel or the protocol on the interface changed state:
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up
%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up.!!!
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed state to down
The following line indicates that the channel was disabled:
BRI: disable channel B1
Lines of output not described are for use by support staff only.
Related Commands
debug isdn-event
debug isdn-q921
debug isdn-q931
Debug Commands 2-59
debug broadcast
debug broadcast
Use the debug broadcast EXEC command to display information on MAC broadcast packets. The
debug broadcast
no debug broadcast
Syntax Description
Command Mode
EXEC
Usage Guidelines
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.
Sample Display
Figure 2-31 shows sample debug broadcast output. Notice how similar it is to the debug packet
output.
Figure 2-31 Sample Debug Broadcast Output
router# debug broadcast
Ethernet0: Broadcast ARPA, src 0000.0c00.6fa4, dst ffff.ffff.ffff, type 0x0800,
data 4500002800000000FF11EA7B, len 60
Serial3: Broadcast HDLC, size 64, type 0x800, flags 0x8F00
Serial2: Broadcast PPP, size 128
Serial7: Broadcast FRAME-RELAY, size 174, type 0x800, DLCI 7a
debug broadcast
Table 2-20 Debug Broadcast Field Descriptions
Field Description
Ethernet0 Name of Ethernet interface that received the packet.
Broadcast Indication that this packet was a broadcast packet.
ARPA Indication that this packet uses ARPA-style encapsulation. Possible
encapsulation styles vary depending on the media command mode
(MCM) and encapsulation style, as follows:
Ethernet (MCM)
Encapsulation Style
APOLLO
ARP
ETHERTALK
ISO1
ISO3
LLC2
NOVELL-ETHER
SNAP
FDDI (MCM)
Encapsulation Style
APOLLO
ISO1
ISO3
LLC2
SNAP
Serial (MCM)
Encapsulation Style
BFEX25
BRIDGE
DDN-X25
DDNX25-DCE
ETHERTALK
FRAME-RELAY
HDLC
HDH
LAPB
LAPBDCE
MULTI-LAPB
PPP
SDLC-PRIMARY
SDLC-SECONDARY
SLIP
SMDS
STUN
X25
X25-DCE
Debug Commands 2-61
debug broadcast
Token Ring (MCM)
Encapsulation Style
3COM-TR
ISO1
ISO3
MAC
LLC2
NOVELL-TR
SNAP
VINES-TR
src 0000.0c00.6fa4 MAC address of the node generating the packet.
dst ffff.ffff.ffff.ffff MAC address of the destination node for the packet. This address is
always the MAC broadcast address.
type 0x0800 Packet type (IP in this case).
data ... First 12 bytes of the datagram following the MAC header.
len 60 Length of the message that the interface received from the wire (in
bytes).
size 128 Length of the message that the interface received from the wire (in
bytes).
flags 0x8F00 HDLC or PPP flags field.
DLCI 7a The DLCI number on Frame Relay.
Field Description
debug bsc events
debug bsc events
Use the debug bsc events command to display all events occuring in the Binary Synchronous
Communication (BSC) feature. The no form of this command disables debugging output.
debug bsc events
no debug bsc events
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command traces all interfaces configured with a bsc protocol-group number interface
command.
Sample Display
Figure 2-32 shows sample debug bsc events output.
Figure 2-32 Sample Debug BSC Events Output
router# debug bsc events
BSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFile
0:04:32: BSC: Serial2 :SDI-rx : 9 bytes
BSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Down new_st:TCU_EOFile
BSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Down new_st:TCU_EOFile
BSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Down new_st:TCU_InFile
BSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Idle new_st:TCU_InFile
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2, changed state to up
%LINK-3-UPDOWN: Interface Serial2, changed state to up
BSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Idle new_st:TCU_InFile
BSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Idle new_st:TCU_InFile
BSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Idle new_st:TCU_InFile
0:04:35: BSC: Serial2 :NDI-rx : 3 bytes
Related Command
debug bsc packet
Debug Commands 2-63
debug bsc packet
debug bsc packet
Use the debug bsc packet command to display all frames traveling through the Binary Synchronous
Communication (BSC) feature. The no form of this command disables debugging output.
debug bsc packet
no debug bsc packet
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command traces all interfaces configured with a bsc protocol-group number interface
command.
Sample Display
Figure 2-33 shows sample debug bsc packet output.
Figure 2-33 Sample Debug BSC Packet Output
router# debug bsc packet
0:23:33: BSC: Serial2 :NDI-rx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D4013
0:23:33: BSC: Serial2 :SDI-tx : 12 bytes 00323237FF3232606040402D
0:23:33: BSC: Serial2 :SDI-rx : 2 bytes 1070
0:23:33: BSC: Serial2 :SDI-tx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D4013
0:23:33: BSC: Serial2 :SDI-rx : 2 bytes 1061
0:23:33: BSC: Serial2 :SDI-tx : 5 bytes 00323237FF
Related Command
debug bsc event
debug bstun
debug bstun
Use the debug bstun command to show connection establishment and overall status messages for
the block serial tunnel (BSTUN) connection. The no form of this command disables debugging
output.
debug bstun
no debug bstun
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-34 shows sample debug bstun output.
Figure 2-34 Sample Debug BSTUN Output
router# debug bstun
%BSTUN-6-TCPFINI: peer (all[2])192.195.80.161/1976 closed [previous state open]
BSTUN: Change state for peer (all[2])192.195.80.161/1976 at 4451380 (open->closed)
%BSTUN-6-TCPFINI: peer (all[1])192.195.80.161/1976 closed [previous state open]
BSTUN: Change state for peer (all[1])192.195.80.161/1976 at 4451380 (open->closed)
BSTUN: Change state for peer (all[2])192.195.80.161/1976 at 4451AA0 (closed->opening)
BSTUN: Change state for peer (all[2])192.195.80.161/1976 at 4451AA0 (opening->open wait)
%BSTUN-6-OPENING: CONN: opening peer (all[2])192.195.80.161/1976, 3
%BSTUN-6-OPENED: CONN: peer (all[2])192.195.80.161/1976 opened, [previous state open
wait]
Related Command
debug bstun packet
Debug Commands 2-65
debug bstun packet
debug bstun packet
Use the debug bstun packet command to display packet information on packets traveling through
the BSTUN links. The no form of this command disables debugging output.
debug bstun packet [group] | [group address]
no debug bstun packet [group] | [group address]
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-35 shows sample debug bstun packet output.
Figure 2-35 Sample Debug BSTUN Packet Output
router# debug bstun packet
BSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1
BSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1
BSTUN bsc-local-ack: 0:00:06 Serial2 NDI: Addr: 40 Data: 0227F5C31140C11D60C8
Related Command
debug bstun event
group (Optional) Only packets associated with this BSTUN group
will be traced.
group address (Optional) If both the group and address parameters are
included, only packets with this address and associated
with this BSTUN group will be traced.
debug callback
debug callback
Use the debug callback command to display callback events when the router is using a modem and
a chat script to call back on a terminal line. The no form of this command disables debugging output.
debug callback
no debug callback
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command is useful for debugging chat scripts on PPP and ARAP lines that use callback
mechanisms. The output provided by the debug callback command shows you how the call is
progressing when used with the debug ppp or debug arap commands.
Sample Display
Figure 2-36 shows sample debug callback output.
Figure 2-36 Sample Debug Callback Output
router# debug callback
TTY7 Callback process initiated, user: exec_test dialstring 123456
TTY7 Callback forced wait = 4 seconds
TTY7 Exec Callback Successful - await exec/autoselect pickup
TTY7: Callback in effect
Related Commands
debug ppp
debug arap
Debug Commands 2-67
debug cdp
debug cdp
Use the debug cdp EXEC command to enable debugging of Cisco Discovery Protocol (CDP). The
debug cdp {packets | adjacency | events}
no debug cdp {packets | adjacency | events}
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use debug cdp commands to display information about CDP packet activity, activity between CDP
neighbors, and various CDP events.
Sample Display
Figure 2-37 shows a composite sample output from debug cdp packets, debug cdp adjacency, and
debug cdp events.
Figure 2-37 Sample Debug CDP Output
router# debug cdp packets
CDP packet info debugging is on
router# debug cdp adjacency
CDP neighbor info debugging is on
router# debug cdp events
CDP events debugging is on
CDP-PA: Packet sent out on Ethernet0
CDP-PA: Packet received from gray.cisco.com on interface Ethernet0
CDP-AD: Deleted table entry for violet.cisco.com, interface Ethernet0
CDP-AD: Interface Ethernet2 coming up
CDP-EV: Encapsulation on interface Serial2 failed
The messages displayed by debug cdp commands are self-explanatory.
packets Enables packet-related debugging output.
adjacency Enables adjacency-related debugging output.
events Enables output related related to error messages, such as
detecting a bad checksum.
debug channel love
debug channel love
Use the debug channel love command to display Channel Interface Processor (CIP) love letter
events. This command is valid for the Cisco 7000 series routers only. The no form of this command
debug channel love
no debug channel love
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command displays Channel Interface Processor (CIP) events that occur on the CIP interface
processor and is useful for diagnosing problems in an IBM channel attach network. It provides an
overall picture of the stability of the network. In a stable network, the debug channel love command
returns a statistic message (cip_love_letter) that is transmitted every ten seconds.
Sample Display
Figure 2-38 shows sample debug channel love output.
Figure 2-38 Sample Debug Channel Love Output
Router# debug channel love
Channel3/1: love letter received, bytes 3308
cip_love_letter: recieved ll, but no cip_info
The following line indicates that data was received on the CIP:
The following line indicates that the interface is enabled, but there is no configuration for it. It does
not normally indicate a problem, just that the route processor (RP) got statistics from the CIP but has
no place to store them.
cip_love_letter: recieved ll, but no cip_info
Related Commands
debug channel events
debug channel packets
Debug Commands 2-69
The debug channel events EXEC command displays processing events that occur on the channel
adapter interfaces of all installed adapters. This command is valid for the Cisco 7000 series routers
only. The no form of this command disables debugging output.
no debug channel events
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command displays Channel Interface Processor (CIP) events that occur on the CIP interface
processor and is useful for diagnosing problems in an IBM channel attach network. It provides an
overall picture of the stability of the network. In a stable network, the debug channel events
command does not return any information. If the command generates numerous messages, they can
indicate the possible source of the problems. To observe the statistic message (cip_love_letter)
transmitted every ten seconds, use the debug channel love command.
When configuring or making changes to a router or interface that supports IBM channel attach,
enable debug channel events. Doing so alerts you to the progress of the changes or to any errors
that might result. Also use this command periodically when you suspect network problems.
Sample Display
Figure 2-39 shows sample debug channel events output.
Figure 2-39 Sample Debug Channel Events Output
Router# debug channel events
Channel3/0: cip_reset(), state administratively down
Channel3/0: cip_reset(), state up
Channel3/0: sending nodeid
Channel3/0: sending command for vc 0, CLAW path C700, device C0
The following line indicates that the CIP is being reset to an administrative down state:
Channel3/0: cip_reset(), state administratively down
The following line indicates that the CIP is being reset to an administrative up state:
Channel3/0: cip_reset(), state up
The following line indicates that the node id is being sent to the CIP. This information is the same
as the "Local Node" information under the show extended channel slot/port subchannels
command. The CIP needs this information to send to the host mainframe.
Channel3/0: sending nodeid
The following line indicates that a CLAW subchannel command is being sent from the RP to the CIP.
The value vc 0 indicates that the CIP will use virual circuit number 0 with this device. The virual
circuit number will also show up when you use the debug channel packets command.
Channel3/0: sending command for vc 0, CLAW path C700, device C0
Related Commands
debug channel love
Debug Commands 2-71
Use the debug channel packets EXEC command to display per-packet debugging output. The
output reports information when a packet is received or a transmit is attempted. The no form of this
no debug channel packets
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug channel packets command displays all process-level Channel Interface Processor (CIP)
packets for both outbound and and inbound packets. You will need to disable fast switching and
autonomous switching to obtain debugging output. This command is useful for determining whether
packets are received or transmitted correctly.
This command is valid for the Cisco 7000 series routers only.
Sample Display
Figure 2-40 shows sample debug channel packets output.
Figure 2-40 Sample Debug Channel Packets Output
Router# debug channel packets
Channel packets debugging is on
(Channel3/0)-out size = 104, vc = 0000, type = 0800, src 198.92.0.11, dst 198.92.1.58
(Channel3/0)-in size = 48, vc = 0000, type = 0800, src 198.92.1.58, dst 198.92.15.197
(Channel3/0)-out size = 71, vc = 0000, type = 0800, src 198.92.15.197, dst 198.92.1.58
Table 2-21 provides explanations for individual lines of output from Figure 2-40.
Table 2-21 Channel Packets Field Descriptions
Field Description
(Channel3/0) The interface slot and port.
in / out In is a packet from the mainframe to the router.
Out is a packet from the router to the mainframe.
size = The number of bytes in the packet, including internal overhead.
vc = A value from 0511 that maps to the claw interface configuration
command. This information is from the MAC layer.
Related Commands
debug channel love
type = The encapsulation type in the MAC layer. The value 0800 indicates an
IP datagram.
src The origin, or source, of the packet, as opposed to the previous hop
address.
dst The destination of the packet, as opposed to the next hop address.
Field Description
Debug Commands 2-73
debug clns esis events
Use the debug clns esis events EXEC command to display uncommon End System-to-Intermediate
System (ES-IS) events, including previously unknown neighbors, neighbors that have aged out, and
neighbors that have changed roles (ES to IS, for example). The no form of this command disables
debugging output.
no debug clns esis events
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-41 shows sample debug clns esis events output.
Figure 2-41 Sample Debug CLNS ESIS Events Output
router# debug clns esis events
ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30
ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20
The following line indicates that the router received a hello packet (ISH) from the IS at MAC address
aa00.0400.2c05 on the Ethernet1 interface. The hold time (or number of seconds to consider this
packet valid before deleting it) for this packet is 30 seconds.
ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30
The following line indicates that the router received a hello packet (ESH) from the ES at MAC
address aa00.0400.9105 on the Ethernet1 interface. The hold time is 150 seconds.
ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
The following line indicates that the router sent an IS hello packet on the Ethernet0 interface to all
ESs on the network. The network entity title (NET) address of the router is
49.0001.0400.AA00.6904.00; the hold time for this packet is 299 seconds; and the header length of
this packet is 20 bytes.
ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20
debug clns esis packets
Use the debug clns esis packets EXEC command to enable display information on End
System-to-Intermediate System (ES-IS) packets that the router has received and sent. The no form
of this command disables debugging output.
no debug clns esis packets
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-42 shows sample debug clns esis packets output.
Figure 2-42 Sample Debug CLNS ESIS Packets Output
router# debug clns esis packets
ES-IS: ISH sent to All ESs (Ethernet0): NET
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
ES-IS: ISH sent to All ESs (Tunnel0): NET
47.0005.80ff.ef00.0000.0001.5940.1600.O906.4023.00, HT 299, HLEN 34
IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300
The following line indicates that the router has sent an IS hello packet on Ethernet0 to all ESs on the
network. This hello packet indicates that the NET of the router is
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00. The hold time for this packet is
299 seconds. The packet header is 33 bytes in length.
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33
The following line indicates that the router has sent an IS hello packet on Ethernet1 to all ESs on the
network. This hello packet indicates that the network entity title (NET) of the router is
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
The following line indicates that the router received a hello packet on Ethernet0 from an intermediate
system, aa00.0400.6408. The hold time for this packet is 299 seconds.
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
Debug Commands 2-75
The following line indicates that the router has sent an IS hello packet on Tunnel0 to all ESs on the
network. This hello packet indicates that the NET of the router is
ES-IS: ISH sent to All ESs (Tunnel0): NET
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
The following line indicates that on Ethernet0, the router received a hello packet from an end system
with an SNPA of 0000.0c00.bda8. The hold time for this packet is 300 seconds.
IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300
debug clns events
debug clns events
Use the debug clns events EXEC command to display CLNS events that are occurring at the router.
debug clns events
no debug clns events
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-43 shows sample debug clns events output.
Figure 2-43 Sample Debug CLNS Events Output
router# debug clns events
CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!
CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
CLNS: Forwarding packet size 117
from 39.0001.2222.2222.2222.00
to 49.0002.0001.AAAA.AAAA.AAAA.00
via 49.0002 (Ethernet3 0000.0c00.b5a3)
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3
The following line indicates that the router received an echo PDU on Ethernet3 from source network
service access point (NSAP) 39.0001.2222.2222.2222.00. The exclamation point at the end of the
line has no significance.
CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!
The following lines indicate that the router at source NSAP 39.0001.3333.3333.3333.00 is sending
a CLNS echo packet to destination NSAP 39.0001.2222.2222.2222.00 via an IS with system ID
2222.2222.2222. The packet is being sent on the Ethernet3 interface, with a MAC address of
0000.0c00.3a18.
CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
The following lines indicate that a CLNS echo packet 117 bytes in size is being sent from source
NSAP 39.0001.2222.2222.2222.00 to destination NSAP 49.0002.0001.AAAA.AAAA.AAAA.00
via the router at NSAP 49.0002. The packet is being forwarded on the Ethernet3 interface, with a
MAC address of 0000.0c00.b5a3.
from 39.0001.2222.2222.2222.00
to 49.0002.0001.AAAA.AAAA.AAAA.00
via 49.0002 (Ethernet3 0000.0c00.b5a3)
Debug Commands 2-77
debug clns events
The following lines indicate that the router sent a redirect packet on the Ethernet3 interface to the
NSAP 39.0001.2222.2222.2222.00 at MAC address 0000.0c00.3a18 to indicate that NSAP
49.0002.0001.AAAA.AAAA.AAAA.00 can be reached at MAC address 0000.0c00.b5a3.
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3
debug clns igrp packets
Use the debug clns igrp packets EXEC command to display debugging information on all
ISO-IGRP routing activity. The no form of this command disables debugging output.
no debug clns igrp packets
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-44 shows sample debug clns igrp packets output.
Figure 2-44 Sample Debug CLNS IGRP Packets Output
router# debug clns igrp packets
ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1
ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51
ISO-IGRP: Originating level 1 periodic update
ISO-IGRP: Advertise dest: 2222.2222.2222
ISO-IGRP: Sending update on interface: Ethernet3
ISO-IGRP: Advertise dest: 0001
ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)
ISO-IGRP: Opcode: area
ISO-IGRP: Received level 2 adv for 0001 metric 1100
ISO-IGRP: Opcode: station
ISO-IGRP: Received level 1 adv for 3333.3333.3333 metric 1100
The following line indicates that the router is sending a hello packet to advertise its existence in the
DOMAIN_green1 domain:
ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1
The following line indicates that the router received a hello packet from a certain network service
access point (NSAP) on the Ethernet3 interface. The hold time for this information is 51 seconds.
ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51
The following lines indicate that the router is generating a Level 1 update to advertise reachability
to destination NSAP 2222.2222.2222 and that it is sending that update to all systems that can be
reached through the Ethernet3 interface:
ISO-IGRP: Advertise dest: 2222.2222.2222
Debug Commands 2-79
The following lines indicate that the router is generating a Level 2 update to advertise reachability
to destination area 1 and that it is sending that update to all systems that can be reached through the
Ethernet3 interface:
ISO-IGRP: Advertise dest: 0001
The following lines indicate that the router received an update from NSAP 3333.3333.3333 on
Ethernet3. This update indicated the area the router at this NSAP could reach.
ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)
ISO-IGRP: Opcode: area
The following lines indicate that the router received an update advertising that the source of that
update can reach area 1 with a metric of 1100. A station opcode indicates that the update included
system addresses.
ISO-IGRP: Received level 2 adv for 0001 metric 1100
ISO-IGRP: Opcode: station
debug clns packet
debug clns packet
Use the debug clns packet EXEC command to display information about packet receipt and
forwarding to the next interface. The no form of this command disables debugging output.
debug clns packet
no debug clns packet
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-45 shows sample debug clns packet output.
Figure 2-45 Sample Debug CLNS Packet Output
router# debug clns packet
from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
CLNS: Echo PDU received on Ethernet0 from 4
7.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
In the following lines, the first line indicates that a Connectionless Network Service (CLNS) packet
of size 157 bytes is being forwarded. The second line indicates the network service access point
(NSAP) and system name of the source of the packet. The third line indicates the destination NSAP
for this packet. The fourth line indicates the next-hop system ID, interface, and SNPA of the router
interface used to forward this packet.
from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
In the following lines, the first line indicates that the router received an Echo PDU on the specified
interface from the source NSAP. The second line indicates which source NSAP is used to send a
CLNS packet to the destination NSAP, as shown on the third line. The fourth line indicates the
next-hop system ID, interface, and SNPA of the router interface used to forward this packet.
CLNS: Echo PDU received on Ethernet0 from
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
Debug Commands 2-81
debug clns routing
debug clns routing
Use the debug clns routing EXEC command to display debugging information for all
Connectionless Network Service (CLNS) routing cache updates and activities involving the CLNS
routing table. The no form of this command disables debugging output.
debug clns routing
no debug clns routing
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-46 shows sample debug clns routing output.
Figure 2-46 Sample Debug CLNS Routing Output
router# debug clns routing
CLNS-RT: cache increment:17
CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002
CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
The following line indicates that a change to the routing table has resulted in an addition to the
fast-switching cache:
CLNS-RT: cache increment:17
The following line indicates that a specific prefix route was added to the routing table, and indicates
the next-hop system ID to that prefix route. In other words, when the router receives a packet with
the prefix 47.0023.0001.0000.0000.0003.0001 in that packets destination address, it forwards that
packet to the router with the MAC address 1920.3614.3002.
CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002
The following lines indicate that the fast-switching cache entry for a certain network service access
point (NSAP) has been invalidated and then deleted:
CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
debug compress
debug compress
Use the debug compress EXEC command to display compression information. The no form of this
debug compress
no debug compress
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-47 shows sample debug compress output.
Figure 2-47 Sample Debug Compress Output
router# debug compress
DECOMPRESS xmt_paks 5 rcv_sync 5
COMPRESS xmt_paks 10 version 1
Table 2-22 Debug Compress Field Descriptions
Field Description
COMPRESS xmt_paks The sequence count of this frame is modulo 256 (except zero only occurs on
initialization). This value is part of the compression header sent with each frame.
DECOMPRESS xmt_paks The sequence count in the compression header received with this frame.
DECOMPRESS rcv_sync The received internal sequence count, which is verified against the DECOMPRESS
xmt_paks count. If these counts do not match, a Link Access Procedure, Balanced
(LAPB) reset will occur. On LAPB reset, a compression reinitialization occurs.
Compression reinitialization initializes the dictionaries and xmt_paks and rcv_sync
counts.
Debug Commands 2-83
debug decnet adj
debug decnet adj
Use the debug decnet adj EXEC command to display debugging information on DECnet
adjacencies. The no form of this command disables debugging output.
debug decnet adj
no debug decnet adj
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-48 shows sample debug decnet adj output.
Figure 2-48 Sample Debug DECnet Adj Output
router# debug decnet adj
DECnet adjacencies debugging is on
router#
DNET-ADJ: Level 1 hello from 1.3
DNET-ADJ: sending hellos
DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498
DNET-ADJ: 1.5 adjacency initializing
DNET-ADJ: sending triggered hellos
DNET-ADJ: 1.5 adjacency up
DNET-ADJ: 1.5 adjacency down, listener timeout
The following line indicates that the router is sending hellos to all routers on this segment, which in
this case is Ethernet 0:
The following line indicates that the router has heard a hello from address 1.5 and is creating an
adjacency entry in its table. The initial state of this adjacency will be initializing.
DNET-ADJ: 1.5 adjacency initializing
The following line indicates that the router is sending an unscheduled (triggered) hello as a result of
some event, such as new adjacency being heard:
DNET-ADJ: sending triggered hellos
The following line indicates that the adjacency with 1.5 is now up, or active:
DNET-ADJ: 1.5 adjacency up
debug decnet adj
The following line indicates that the adjacency with 1.5 has timed out, because no hello has been
heard from adjacency 1.5 in the time interval originally specified in the hello from 1.5:
DNET-ADJ: 1.5 adjacency down, listener timeout
The following line indicates that the router is sending an unscheduled hello, as a result of some event,
such as the adjacency state changing:
DNET-ADJ: hello update triggered by state changed in dn_add_adjacency
Debug Commands 2-85
debug decnet connects
Use the debug decnet connects EXEC command to display debugging information of all connect
packets that are filtered (permitted or denied) by DECnet access lists. The no form of this command
no debug decnet connects
Syntax Description
Command Mode
EXEC
Usage Guidelines
When you use 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 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.
Sample Display
Figure 2-49 shows sample debug decnet connects output.
Figure 2-49 Sample Debug DECnet Connects Output
router# debug decnet connects
DNET-CON: list 300 item #2 matched src=19.403 dst=19.309 on Ethernet0: permitted
srcname="RICK" srcuic=[0,017]
dstobj=42 id="USER"
Table 2-23 Debug DECnet Connects Field Descriptions
Field Description
DNET-CON: Indicates that this is a debug decnet connects packet
list 300 item #2 matched Indicates that a packet matched the second item in access list 300
src = 19.403 Indicates the source DECnet address for the packet
dst = 19.309 Indicates the destination DECnet address for the packet
on Ethernet0: Indicates the router interface on which the access list filtering the
packet was applied
permitted Indicates that the access list permitted the packet
srcname = RICK Indicates the originator user of the packet
Note Packet password and account information is not logged in the debug decnet connects
message, nor is it displayed by the show access EXEC command. If you specify password or
account information in your access list, they can be viewed by anyone with access to the
configuration of the router.
srcuic = [0,017] Indicates the source UIC of the packet
dstobj = 42 Indicates that DECnet object 42 is the destination
id=USER Indicates the access user
Field Description
Debug Commands 2-87
debug decnet events
debug decnet events
Use the debug decnet events EXEC command to display debugging information on DECnet events.
debug decnet events
no debug decnet events
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-50 shows sample debug decnet events output.
Figure 2-50 Sample Debug DECnet Events Output
router# debug decnet events
DNET: Hello from area 50 rejected - exceeded max area' parameter (45)
DNET: Hello from area 50 rejected - exceeded max area' parameter (45)
The following line indicates that the router received a hello from a router whose area was greater
than the max-area parameter with which this router was configured:
DNET: Hello from area 50 rejected - exceeded 'max area' parameter (45)
The following line indicates that the router received a hello from a router whose node ID was greater
than the max-node parameter with which this router was configured:
DNET: Hello from node 1002 rejected - exceeded 'max node' parameter (1000)
debug decnet packet
debug decnet packet
Use the debug decnet packet EXEC command to display debugging information on DECnet packet
events. The no form of this command disables debugging output.
debug decnet packet
no debug decnet packet
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-51 shows sample debug decnet packet output.
Figure 2-51 Sample Debug DECnet Packet Output
router# debug decnet packet
DNET-PKT: src 1.4 dst 1.5 sending to PHASEV
DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0
The following line indicates that the router is sending a converted packet addressed to node 1.5 to
Phase V:
DNET-PKT: src 1.4 dst 1.5 sending to PHASEV
The following line indicates that the router forwarded a packet from node 1.4 to node 1.5. The packet
is being sent to the next hop of 1.5 whose subnetwork point of attachment (MAC address) on that
interface is 0000.3080.cf90.
DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0
Debug Commands 2-89
debug decnet routing
Use the debug decnet routing EXEC command to display all DECnet routing-related events
occurring at the router. The no form of this command disables debugging output.
no debug decnet routing
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-52 shows sample debug decnet routing output.
Figure 2-52 Sample Debug DECnet Routing Output
router# debug decnet routing
DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34
DNET-RT: Sending routes
DNET-RT: Sending normal routing updates on Ethernet0
DNET-RT: Sending level 1 routing updates on interface Ethernet0
DNET-RT: Level1 routes from 1.5 on Ethernet0: entry for node 5 created
DNET-RT: route update triggered by after split route pointers in dn_rt_input
DNET-RT: Received level 1 routing from 1.5 on Ethernet 0 at 1:18:35
DNET-RT: Sending L1 triggered routes
DNET-RT: Sending L1 triggered routing updates on Ethernet0
DNET-RT: removing route to node 5
The following line indicates that the router has received a level 1 update on interface Ethernet 0:
DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34
The following line indicates that the router is sending its scheduled updates on interface Ethernet 0:
DNET-RT: Sending normal routing updates on Ethernet0
The following line indicates that the route will send an unscheduled update on this interface as a
result of some event. In this case, the unscheduled update is a result of a new entry created in the
interfaces routing table.
DNET-RT: route update triggered by after split route pointers in dn_rt_input
The following line indicates that the router sent the unscheduled update on Ethernet 0:
DNET-RT: Sending L1 triggered routes
DNET-RT: Sending L1 triggered routing updates on Ethernet0
The following line indicates that the router removed the entry for node 5 because the adjacency with
node 5 timed out, or the route to node 5 through a next-hop router went away:
DNET-RT: removing route to node 5
Debug Commands 2-91
debug dialer
debug dialer
Use the debug dialer EXEC command to display debugging information about the packets that are
received on a dialer interface. The no form of this command disables debugging output.
debug dialer
no debug dialer
Syntax Description
Command Mode
EXEC
Usage Guidelines
Table 2-24 describes the error messages that the debug dialer command can generate for a serial
interface being used as a V.25bis dialer for dial-on-demand routing (DDR).
Table 2-24 Debug Dialer Message Descriptions for DDR
When DDR is enabled on the interface, information concerning the cause of any calls (called Dialing
cause) may be displayed.
Message Description
Serial 0: Dialer result = xxxxxxxxxx This message displays the result returned from the V.25bis
dialer. It is useful in debugging if calls are failing. On some
hardware platforms, this message cannot be displayed due to
hardware limitations. Possible values for the xxxxxxxxxx variable
depend on the V.25bis device with which the router is
communicating.
Serial 0: No dialer string defined.
Dialing cannot occur.
This message is displayed when a packet is received that should
cause a call to be placed. However, there is no dialer string
configured, so dialing cannot occur. This message usually
indicates a configuration problem.
Serial 0: Attempting to dial xxxxxxxxxx This message indicates that a packet has been received that
passes the dial-on-demand access lists. That packet causes
dialing of a phone number. The xxxxxxxxxx variable is the
number being called.
Serial 0: Unable to dial xxxxxxxxxx This message is displayed if for some reason, the phone call
could not be placed. This might be due to a lack of memory, full
output queues, or other problems.
Serial 0: disconnecting call This message is displayed when the router attempts to hang up a
call.
Serial 0: idle timeout
Serial 0: re-enable timeout
Serial 0: wait for carrier timeout
One of these three messages is displayed when their
corresponding dialer timer expires. They are mostly
informational, but are useful when debugging a disconnected
call or call failure.
debug dialer
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 the Ethernet Type Codes appendix of the
Router Products Command Reference publication.
Dialing cause: Serial1: Bridge (0x6005)
Debug Commands 2-93
debug dlsw
debug dlsw
Use the debug dlsw EXEC command to enable debugging of data-link switching (DLSw). The no
form of this command disables debugging output.
debug dlsw [core | peers | reachability ]
no debug dlsw [core | peers | reachability]
Syntax Description
Command Mode
EXEC
Usage Guidelines
When you specify no optional keywords, the debug dlsw command enables all available DLSw
debugging output.
Sample Display
Figure 2-53 shows sample debug dlsw output.
Figure 2-53 Sample Debug DLSw Output
router# debug dlsw
DLSw reachability debugging is on
DLSw peer debugging is on
Data Link Switching Core:
DLSw core XID C/R debugging is on
DLSw core flow-control debugging is on
DLSw core flow-control sender debugging is on
DLSw core flow-control receiver debugging is on
DLSw core flow-control sender debugging is on
DLSw core messages debugging is on
DLSw core errors debugging is on
DLSw core states debugging is on
DLSw core all debugging is on
The lines of output in Figure 2-53 show that all possible debugging is enabled.
core (Optional) Enables DLSw core debugging output.
peers (Optional) Enables peer events debugging output.
reachability (Optional) Enables reachability events (explorer traffic)
debugging output.
debug dspu activation
Use the debug dspu activation EXEC command to display information on downstream physical
unit (DSPU) activation. The no form of this command disables debugging output.
debug dspu activation [name]
no debug dspu activation [name]
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug dspu activation command displays all DSPU activation traffic. To restrict the output to
a specific host or physical unit (PU), include the host or PU name argument. You cannot turn off
debugging output for an individual PU if that PU has not been named in the debug dspu activation
command.
Sample Display
Figure 2-54 shows sample debug dspu activation output. Not all intermediate numbers are shown
for the activated and deactivated logical unit (LU) address ranges.
Figure 2-54 Sample Debug DSPU Activation Output
router# debug dspu activation
DSPU: LS HOST3745 connected
DSPU: PU HOST3745 activated
DSPU: LU HOST3745-2 activated
. . .
DSPU: LU HOST3745-2 deactivated
. . .
DSPU: LS HOST3745 disconnected
DSPU: PU HOST3745 deactivated
name (Optional) A host or PU name designation.
Debug Commands 2-95
Table 2-25 Debug DSPU Activation Field Descriptions
Related Commands
debug dspu packet
debug dspu state
debug dspu trace
Field Description
DSPU Downstream PU debug message.
LS A link station (LS) event triggered the message.
PU A PU event triggered the message.
LU A logical unit (LU) event triggered the message.
HOST3745 Host name or PU name.
HOST3745-253 Host name or PU name and the LU address, separated by a colon.
connected
activated
disconnected
deactivated
Event that occurred to trigger the message.
debug dspu packet
debug dspu packet
Use the debug dspu packet EXEC command to display information on downstream physical unit
(DSPU) packet. The no form of this command disables debugging output.
debug dspu packet [name]
no debug dspu packet [name]
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug dspu packet command displays all DSPU packet data flowing through the router. To
restrict the output to a specific host or PU, include the host or PU name argument. You cannot turn
off debugging output for an individual PU if that PU has not been named in the debug dspu packet
command.
Sample Display
Figure 2-55 shows sample debug dspu packet output.
Figure 2-55 Sample Debug DSPU Packet Output
router# debug dspu packet
DSPU: Rx: PU HOST3745 data length 12 data:
2D0003002BE16B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
2D0000032BE1EB80 000D020100850000 000C060000010000 00
DSPU: Rx: PU HOST3745 data length 12 data:
2D0004002BE26B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
2D0000042BE2EB80 000D020100850000 000C060000010000 00
Table 2-26 Debug DSPU Packet Field Descriptions
Field Description
DSPU: Rx: Received frame (packet) from the remote PU to the router PU.
DSPU: Tx: Transmitted frame (packet) from the router PU to the remote PU.
PU HOST3745 Host name or PU associated with the transmit or receive.
data length 12 data: Number of bytes of data, followed by up to 128 bytes of displayed data.
Debug Commands 2-97
debug dspu packet
Related Commands
debug dspu state
debug dspu trace
debug dspu state
debug dspu state
Use the debug dspu state EXEC command to display information on downstream physical unit
(DSPU) finite state machine (FSM) state changes. The no form of this command disables debugging
output.
debug dspu state [name]
no debug dspu state [name]
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use the debug dspu state command to display only the FSM state changes. To see all FSM activity,
use the debug dspu trace command. You cannot turn off debugging output for an individual PU if
that PU has not been named in the debug dspu state command.
Sample Display
Figure 2-56 shows sample debug dspu state output. Not all intermediate numbers are shown for the
activated and deactivated logical unit (LU) address ranges.
Figure 2-56 Sample Debug DSPU State Output
router# debug dspu state
DSPU: LS HOST3745: input=StartLs, Reset -> PendConOut
DSPU: LS HOST3745: input=ReqOpn.Cnf, PendConOut -> Xid
DSPU: LS HOST3745: input=Connect.Ind, Xid -> ConnIn
DSPU: LS HOST3745: input=Connected.Ind, ConnIn -> Connected
DSPU: PU HOST3745: input=Actpu, Reset -> Active
DSPU: LU HOST3745-2: input=uActlu, Reset -> upLuActive
. . .
DSPU: LS HOST3745: input=PuStopped, Connected -> PendDisc
DSPU: LS HOST3745: input=Disc.Cnf, PendDisc -> PendClose
DSPU: LS HOST3745: input=Close.Cnf, PendClose -> Reset
DSPU: PU HOST3745: input=T2ResetPu, Active -> Reset
DSPU: LU HOST3745-2: input=uStopLu, upLuActive -> Reset
. . .
Debug Commands 2-99
debug dspu state
Table 2-27 Debug DSPU State Field Descriptions
Related Commands
debug dspu packet
debug dspu trace
Field Description
HOST3745-253 Host name or PU name and LU address.
input=input, The input received by the FSM.
previous-state, -> current-state The previous state and current new state as seen by the FSM.
debug dspu trace
debug dspu trace
Use the debug dspu trace EXEC command to display information on downstream physical unit
(DSPU) trace activity, which includes all finite state machine (FSM) activity. The no form of this
debug dspu trace [name]
no debug dspu trace [name]
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use the debug dspu trace command to display all FSM state changes. To see FSM state changes
only, use the debug debug dspu state command. You cannot turn off debugging output for an
individual PU if that PU has not been named in the debug dspu trace command.
Sample Display
Figure 2-57 shows sample debug dspu trace output.
Figure 2-57 Sample Debug DSPU Trace Output
router# debug dspu trace
DSPU: LS HOST3745 input = 0 ->(1,a1)
DSPU: LU HOST3745-2 in:0 s:0->(2,a1)
DSPU: LU HOST3745-3 in:0 s:0->(2,a1)
DSPU: LU HOST3745-252 in:0 s:0->(2,a1)
DSPU: LU HOST3745-253 in:0 s:0->(2,a1)
DSPU: LU HOST3745-254 in:0 s:0->(2,a1)
Debug Commands 2-101
debug dspu trace
Table 2-28 Debug DSPU Trace Field Descriptions
Related Commands
debug dspu packet
debug dspu state
Field Description
7:23:57 Time stamp.
HOST3745-253 Host name or PU name and LU address.
in:input s:state ->(new-state,
action)
String describing the following:
input - LU FSM input
state - Current FSM state
new-state - New FSM state
action - FSM action
input=input ->
(new-state,action)
String describing the following:
input - PU or LS FSM input
new-state - New PU or LS FSM state
action - PU or LS FSM action
debug eigrp fsm
debug eigrp fsm
Use the debug eigrp fsm EXEC command to display debugging information about Enhanced IGRP
feasible successor metrics (FSM). The no form of this command disables debugging output.
debug eigrp fsm
no debug eigrp fsm
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command helps you observe Enhanced IGRP feasible successor activity and to determine
whether route updates are being installed and deleted by the routing process.
Sample Display
Figure 2-58 shows sample debug eigrp fsm output.
Figure 2-58 Sample Debug EIGRP FSM Output
router# debug eigrp fsm
DUAL: dual_rcvupdate(): 198.93.166.0 255.255.255.0 via 0.0.0.0 metric 750080/0
DUAL: Find FS for dest 198.93.166.0 255.255.255.0. FD is 4294967295, RD is 42949
67295 found
DUAL: RT installed 198.93.166.0 255.255.255.0 via 0.0.0.0
DUAL: dual_rcvupdate(): 192.168.4.0 255.255.255.0 via 0.0.0.0 metric 4294967295/
4294967295
DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295
DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state.
DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0
DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0
In the first line of Figure 2-58, DUAL stands for Diffusing Update ALgorithm. It is the basic
mechanism within Enhanced IGRP that makes the routing decisions.The next three fields are the
Internet address and mask of the destination network and the address through which the update was
received. The metric field shows 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 no longer has a route to the destination, or the destination is in holddown.
In the following output, Enhanced IGRP is attempting to find a feasible successor for the destination.
Feasible successors are part of the DUAL loop avoidance methods. The FD field contains more loop
avoidance state information. The RD field is the reported distance, which is the metric used in
update, query or reply packets.
debug eigrp fsm
The indented line with the not found message means a feasible successor (FS) was not found for
192.168.4.0 and EIGRP must start a diffusing computation. This means it begins to actively probe
(sends query packets about destination 192.168.4.0) the network looking for alternate paths to
192.164.4.0.
DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295
The following output indicates the route DUAL successfully installed into the routing table.
DUAL: RT installed 198.93.166.0 255.255.255.0 via 0.0.0.0
The following output shows that no routes were discovered to the destination and the route
information is being removed from the topology table.
DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state.
DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0
DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0
debug eigrp packet
debug eigrp packet
Use the debug eigrp packet EXEC command to display general debugging information. The no
debug eigrp packet
no debug eigrp packet
Syntax Description
Command Mode
EXEC
Usage Guidelines
If a communication session is closing when it should not be, an end-to-end connection problem can
be the cause. The debug eigrp packet command is useful for analyzing the messages traveling
between the local and remote hosts.
Sample Display
Figure 2-59 shows sample debug eigrp packet output.
Figure 2-59 Sample Debug EIGRP Packet Output
router# debug eigrp packet
EIGRP: Sending HELLO on Ethernet0/1
AS 109, Flags 0x0, Seq 0, Ack 0
EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,
EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,
EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,
EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,
The output shows transmission and receipt of Enhanced IGRP packets. These packet types may be
HELLO, UPDATE, REQUEST, QUERY, or REPLY packets. The sequence and acknowledgement
numbers used by the Enhanced IGRP reliable transport algorithm are shown in the output. Where
applicable, the network layer address of the neighboring router is also included.
debug eigrp packet
Table 2-29 Debug EIGRP Packet Field Descriptions
Field Description
EIGRP: An Enhanced IGRP packet.
AS n Autonomous system number.
Flags nxn A flag of 1 means the sending router is indicating to the receiving router
that this is the first packet it has sent to the receiver.
A flag of 2 is a multicast that should be conditionally received by routers
that have the conditionally-receive (CR) bit set. This bit gets set when
the sender of the multicast has previously sent a sequence packet
explicitly telling it to set the CR bit.
HELLO The hello packets are the neighbor discovery packets. They are used to
determine whether neighbors are still alive. As long as neighbors receive
the hello packets the router is sending, the neighbors validate the router
and any routing information sent. If neighbors lose the hello packets, the
receiving neighbors invalidate any routing information previously sent.
Neighbors also transmit hello packets.
debug frame-relay
debug frame-relay
Use the debug frame-relay EXEC command to display debugging information about the packets
that are received on a Frame Relay interface. The no form of this command disables debugging
output.
debug frame-relay
no debug frame-relay
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command helps you analyze the packets that have been received. However, because the debug
frame-relay command generates a lot of output, only use it when traffic on the Frame Relay network
is less than 25 packets per second.
To analyze the packets that have been sent on a Frame Relay interface, use the debug frame-relay
packets command.
Sample Display
Figure 2-60 shows sample debug frame-relay output.
Figure 2-60 Sample Debug Frame-Relay Output
router# debug frame-relay
Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Table 2-30 Debug Frame-Relay Field Descriptions
Field Description
Serial0(i): Indicates that the Serial0 interface has received this Frame Relay
datagram as input.
dlci 500(0x7C41) Indicates the value of the data link connection identifier (DLCI) for this
packet in decimal (and q922). In this case, 500 has been configured as
the multicast DLCI.
debug frame-relay
pkt type 0x809B Indicates the packet type code.
Possible supported signaling message codes follow:
0x308Signaling message; valid only with a DLCI of 0.
0x309LMI message; valid only with a DLCI of 1023
Possible supported Ethernet type codes follow:
0x0201IP on 3MB net
0x0201Xerox ARP on 10MB nets
0xCCRFC 1294 (only for IP)
0x0600XNS
0x0800IP on 10 MB net
0x0806IP ARP
0x0808Frame Relay ARP
0x0BADVINES IP
0x0BAEVINES loopback protocol
0x0BAFVINES Echo
0x6001DEC MOP booting protocol
0x6002DEC MOP console protocol
0x6003DECnet Phase IV on Ethernet
0x6004DEC LAT on Ethernet
0x8005HP Probe
0x8035RARP
0x8038DEC spanning tree
0x809bApple EtherTalk
0x80f3AppleTalk ARP
0x8019Apollo domain
0x80C4VINES IP
0x80C5 VINES ECHO
0x8137IPX
0x9000Ethernet loopback packet IP
Field Description
debug frame-relay
pkt type 0x809B (continued) Possible HDLC type codes follow:
0x1A58 IPX, standard form
0xFEFECLNS
0xEFEFES-IS
0x1998Uncompressed TCP
0x1999Compressed TCP
0x6558Serial line bridging
datagramsize 24 Indicates size of this datagram in bytes.
Field Description
debug frame-relay events
Use the debug frame-relay events EXEC command to display debugging information about Frame
Relay ARP replies on networks that support a multicast channel and use dynamic addressing. The
no debug frame-relay events
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command is useful for identifying the cause of end-to-end connection problems during the
installation of a Frame Relay network or node.
Note Because the debug frame-relay events command does not generate much output, you can
use it at any time, even during periods of heavy traffic, without adversely affecting other users on the
system.
Sample Display
Figure 2-61 shows sample debug frame-relay events output.
Figure 2-61 Sample Debug Frame-Relay Events Output
router# debug frame-relay events
Serial2(i): reply rcvd 131.108.170.26 126
As Figure 2-61 shows, debug 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 data link connection
identifier (DLCI) to use when communicating with the responding router.
debug frame-relay lmi
Use the debug frame-relay lmi EXEC command to display information on the local management
interface (LMI) packets exchanged by the router and the Frame Relay service provider. The no form
no debug frame-relay lmi
Syntax Description
Command Mode
EXEC
Usage Guidelines
You can use this command to determine whether the router and the Frame Relay switch are sending
and receiving LMI packets properly.
Note Because the debug frame-relay lmi command does not generate much output, you can use
it at any time, even during periods of heavy traffic, without adversely affecting other users on the
system.
Sample Display
Figure 2-62 shows sample debug frame-relay lmi output.
Figure 2-62 Sample Debug Frame-Relay LMI Output
router# debug frame-relay lmi
Serial1(out): StEnq, clock 20212760, myseq 206, mineseen 205, yourseen 136, DTE up
Serial1(in): Status, clock 20212764, myseq 206
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 138, myseq 206
Serial1(in): Status, clock 20222764, myseq 207
Serial1(out): clock 20232760, myseq 208, mineseen 207, yourseen 140, line up
Serial1(in): Status, clock 20252764,
PVC IE 0x7, length 0x6, dlci 400, status 0, bw 56000
PVC IE 0x7, length 0x6, dlci 401, status 0, bw 56000
S
2
5
4
6
LMI
exchange
Full LMI
status
message
In Figure 2-62, the first four lines describe an LMI exchange. The first line describes the LMI request
the router has sent to the switch. The second line describes the LMI reply the router has received
from the switch. The third and fourth lines describe the response to this request from the switch. This
LMI exchange is followed by two similar LMI exchanges. The last six lines in Figure 2-62 consist
of a full LMI status message that includes a description of the routers two permanent virtual circuits
(PVCs).
Table 2-31 describes significant fields in the first line of the debug frame-relay lmi output shown
in Figure 2-62.
Table 2-31 Debug Frame-Relay LMI Field DescriptionsPart 1
Table 2-32 describes significant fields in the third and fourth lines of debug frame-relay lmi output
shown in Figure 2-62.
Field Description
Serial1(out) Indication that the LMI request was sent out on the Serial1 interface.
StEnq Command mode of message:
StEnqStatus inquiry
StatusStatus reply
clock 20212760 System clock (in milliseconds). Useful for determining whether an appropriate
amount of time has transpired between events.
myseq 206 The myseq counter maps to the routers CURRENT SEQ counter.
yourseen 136 The yourseen counter maps to the LAST RCVD SEQ counter of the switch.
DTE up Line protocol up/down state for the DTE (user) port.
Field Description
RT IE 1 Value of the report type information element.
length 1 Length of the report type information element (in bytes).
type 1 Report type in RT IE.
KA IE 3 Value of the keepalive information element.
length 2 Length of the keepalive information element (in bytes).
yourseq 138 The yourseq counter maps to the CURRENT SEQ counter of the switch.
myseq 206 The myseq counter maps to the routers CURRENT SEQ counter.
Table 2-33 describes significant fields in the last line of debug frame-relay lmi output shown in
Figure 2-62.
Field Description
PVC IE 0x7 Value of the permanent virtual circuit information element type.
length 0x6 Length of the PVC IE (in bytes).
dlci 401 DLCI decimal value for this PVC.
status 0 Status value. Possible values include the following:
0x00Added/inactive
0x02Added/active
0x04Deleted
0x08New/inactive
0x0aNew/active
bw 56000 CIR (committed information rate), in decimal, for the DLCI.
debug frame-relay packets
Use the debug frame-relay packets EXEC command to display information on packets that have
been sent on a Frame Relay interface. The no form of this command disables debugging output.
no debug frame-relay packets
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command helps you analyze the packets that are sent on a Frame Relay interface. Because the
debug frame-relay packets command generates large amounts of output, only use it when traffic
on the Frame Relay network is less than 25 packets per second.
To analyze the packets received on a Frame Relay interface, use the debug frame-relay command.
Sample Display
Figure 2-63 shows sample debug frame-relay packets output.
Figure 2-63 Sample Debug Frame-Relay Packets Output
As Figure 2-63 shows, debug frame-relay packets output consists 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 data link connection identifiers (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 2-63 describe a single Frame Relay packet
that was sent out on two DLCIs.
router# debug frame-relay packets
Serial0: broadcast = 1, link 809B, addr 65535.255
Serial0(o):DLCI 500 type 809B size 24
Serial0: broadcast - 0, link 809B, addr 10.2
Serial0: broadcast search
S
2
5
4
7
Groups of
output lines
Table 2-34 describes significant fields shown in the first pair of output lines in Figure 2-63.
Table 2-34 Debug Frame-Relay Packets Field Descriptions
Explanations for other lines of output shown in Figure 2-63 follow:
The following lines describe a Frame Relay packet sent to a particular address; in this case
AppleTalk address 10.2:
Serial0: broadcast - 0, link 809B, addr 10.2
The following lines describe a Frame Relay packet that went out on two different DLCIs, because
two Frame Relay map entries were found:
The following lines do not appear in Figure 2-63. They describe a Frame Relay packet sent to a true
broadcast address.
Serial1(o):DLCI 400 type 800 size 288
Field Description
Serial0: Interface that has sent the Frame Relay packet.
broadcast = 1 Destination of the packet. Possible values include the following:
broadcast = 1Broadcast address
broadcast = 0Particular destination
broadcast searchSearches all Frame Relay map entries for this particular protocol
that include the keyword broadcast.
link 809B Link type, as documented under debug frame relay.
addr 65535.255 Destination protocol address for this packet. In this case, it is an AppleTalk address.
Serial0(o): (o) indicates that this is an output event.
DLCI 500 Decimal value of the DLCI.
type 809B Packet type, as documented under debug frame-relay.
size 24 Size of this packet (in bytes).
debug ip dvmrp
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
debug ip dvmrp [detail]
no debug ip dvmrp
Syntax Description
Command Mode
EXEC
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 Display
Figure 2-64 shows sample debug ip dvmrp output.
Figure 2-64 Sample Debug IP DVMRP Output
router# debug ip dvmrp
DVMRP: Received Report on Ethernet0 from 131.119.244.10
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 Tunnel0 from 198.104.199.254
DVMRP: Building Report for Tunnel0 224.0.0.4
DVMRP: Send Report on Tunnel0 to 198.104.199.254
DVMRP: Radix tree walk suspension
The following lines show that the router received DVMRP routing information and placed it in the
mroute table:
detail (Optional) Enables a more detailed level of output and
displays packet contents.
debug ip dvmrp
The following lines show that the router is creating a report to send to other DVMRP router:
DVMRP: Building Report for Ethernet0 224.0.0.4
DVMRP: Send Report on Ethernet0 to 224.0.0.4
Table 2-35 provides a list of internet multicast addresses supported for host IP implementations.
Table 2-35 Internet Multicast Addresses
The following lines show that a protocol update report has been sent to all known multicast groups.
Hosts use IGMP reports to communiate 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.
Figure 2-65 shows sample debug ip dvmrp detail output.
Figure 2-65 Sample Debug IP DVMRP Detail Output
router# debug ip dvmrp detail
DVMRP: Advertise group 224.2.224.2 on Ethernet0
DVMRP: Origin 150.166.53.0/24, metric 13, distance 0
The following lines show that this group is available to the DVMRP router. The mrouted process on
the host will forward the S,G information for theis group through the DVMRP cloud so other
members will know this S,G is available.
Address Description RFC
224.0.0.0 Base address (Reserved) RFC 1112
224.0.0.1 All systems on this subnet RFC 1112
224.0.0.2 All routers on this subnet
224.0.0.3 Unassigned
224.0.0.4 DVMRP routers RFC 1075
224.0.0.5 OSPFIGP all routers RFC 1583
debug ip dvmrp
The following lines show the DVMRP route information:
Metric is the number of hops the route has covered. Distance is the administrative distance.
debug ip eigrp
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.
debug ip eigrp
no debug ip eigrp
Syntax Description
Command Mode
EXEC
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
Figure 2-66 shows sample debug ip eigrp output.
Figure 2-66 Sample Debug IP EIGRP Output
router# debug ip eigrp
IP-EIGRP: Processing incoming UPDATE packet
IP-EIGRP: Ext 198.135.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256
000 104960
IP-EIGRP: Ext 198.135.0.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256
000 104960
IP-EIGRP: Ext 198.135.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256
000 104960
IP-EIGRP: 198.92.43.0 255.255.255.0, - do advertise out Ethernet0/1
IP-EIGRP: Ext 198.92.43.0 255.255.255.0 metric 371200 - 256000 115200
Table 2-36 describes significant fields in the debug messages shown in Figure 2-66.
debug ip eigrp
Table 2-36 Debug IP EIGRP Field Descriptions
Field Description
IP-EIGRP: Indicates that this is an IP Enhanced IGRP packet.
Ext Indicates the following address is an external destination rather than an
internal destination, which would be labeled as Int.
M Shows the computed metric, which includes SM and the cost between
this router and the neighbor. The first number is the composite metric.
The next two numbers are the inverse bandwidth and the delay,
respectively.
SM Shows the metric as reported by the neighbor.
debug ip icmp
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.
debug ip icmp
no debug ip icmp
Syntax Description
Command Mode
EXEC
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
Figure 2-67 shows sample debug ip icmp output.
Figure 2-67 Sample Debug IP ICMP Output
router# debug ip icmp
ICMP: rcvd type 3, code 1, from 128.95.192.4
ICMP: src 36.56.0.202, dst 131.108.16.1, echo reply
ICMP: dst (131.120.1.0) port unreachable rcv from 131.120.1.15
ICMP: dst (255.255.255.255) protocol unreachable rcv from 192.31.7.21
Table 2-37 describes significant fields in the first line of debug ip icmp output shown in Figure 2-67.
debug ip icmp
Table 2-37 Debug IP ICMP Field DescriptionsPart 1
Field Description
ICMP: Indication that this message describes an ICMP packet.
rcvd type 3 The type field can be one of the following:
0Echo Reply
3Destination Unreachable
4Source Quench
5Redirect
8Echo
9Router Discovery Protocol Advertisement
10Router Discovery Protocol Solicitations
11Time Exceeded
12Parameter Problem
13Timestamp
14Timestamp Reply
15Information Request
16Information Reply
17Mask Request
18Mask Reply
code 1 This field is a code. The meaning of the code depends upon the type field
value:
Echo and Echo ReplyThe code field is always zero.
Destination UnreachableThe code field can have the following values:
0Network unreachable
1Host unreachable
2Protocol unreachable
3Port unreachable
4Fragmentation needed and DF bit set
5Source route failed
Source QuenchThe code field is always 0.
RedirectThe code field can have the following values:
0Redirect datagrams for the network
1Redirect datagrams for the host
2Redirect datagrams for the command mode of service and network
3Redirect datagrams for the command mode of service and host
Router Discovery Protocol Advertisements and SolicitationsThe code
field is always zero.
debug ip icmp
Table 2-38 describes significant fields in the second line of debug ip icmp output in Figure 2-67.
Table 2-38 Debug IP ICMP Field DescriptionsPart 2
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 160.89.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 160.89.80.31
ICMP: unexpected mask reply 255.255.255.0 from 160.89.80.32
The following output indicates that the router sent a redirect packet to the host at address
160.89.80.31, instructing that host to use the gateway at address 160.89.80.23 in order to reach the
host at destination address 131.108.1.111:
ICMP: redirect sent to 160.89.80.31 for dest 131.108.1.111 use gw 160.89.80.23
The following message indicates that the router received a redirect packet from the host at address
160.89.80.23, instructing the router to use the gateway at address 160.89.80.28 in order to reach the
host at destination address 160.89.81.34:
ICMP: redirect rcvd from 160.89.80.23 -- for 160.89.81.34 use gw 160.89.80.28
code 1 (continued) Time ExceededThe code field can have the following values:
0Time to live exceeded in transit
1Fragment reassembly time exceeded
Parameter ProblemThe code field can have the following values:
0General problem
1Option is missing
2Option missing, no room to add
Timestamp and Timestamp ReplyThe code field is always zero.
Information Request and Information ReplyThe code field is always
zero.
Mask Request and Mask ReplyThe code field is always zero.
from 128.95.192.4 Source address of the ICMP packet.
Field Description
ICMP: Indication that this message describes an ICMP packet
src 36.56.0.202 The address of the sender of the echo
dst 131.108.16.1 The address of the receiving router
echo reply Indication the router received an echo reply
Field Description
debug ip icmp
The following message is displayed when the router sends an ICMP packet to the source address
(160.89.94.31 in this case), indicating that the destination address (131.108.13.33 in this case) is
unreachable:
ICMP: dst (131.108.13.33) host unreachable sent to 160.89.94.31
The following message is displayed when the router receives an ICMP packet from an intermediate
address (160.89.98.32 in this case), indicating that the destination address (131.108.13.33 in this
case) is unreachable:
ICMP: dst (131.108.13.33) host unreachable rcv from 160.89.98.32
Depending on the code received (as Table 2-37 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 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. The 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 can 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
Note For more information about the fields in debug ip icmp output, see RFC-792, Internet
Control Message Protocol; Appendix I of RFC-950, Internet Standard Subnetting Procedure; and
RFC-1256, ICMP Router Discovery Messages.
debug ip igmp
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
debug ip igmp
no debug ip igmp
Syntax Description
Command Mode
EXEC
Usage Notes
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 the the multicast routing process, or why packets are
forwarded out of particular interfaces.
Sample Display
Figure 2-68 shows sample debug ip igmp output.
Figure 2-68 Sample Debug IP IGMP Output
router# debug ip igmp
IGMP: Received Host-Query from 198.92.37.33 (Ethernet1)
IGMP: Received Host-Report from 198.92.37.192 (Ethernet1) for 224.0.255.1
The messages displayed by the debug ip igmp command show query and report activity received
from other routers and multicast group addresses.
Related Commands
debug ip pim
debug ip mrouting
debug ip igrp events
Use the debug ip igrp events EXEC command to display summary information on Interior Gateway
Routing Protocol (IGRP) routing messages that indicates the source and destination of each update,
as well as the number of routes in each update. Messages are not generated for each route. The no
debug ip igrp events [ip-address]
no debug ip igrp events [ip-address]
Syntax Description
Command Mode
EXEC
Usage Guidelines
If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp events output includes
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 transaction could flood the console and make the router unusable. Use
debug ip igrp events instead to display summary routing information.
Sample Display
Figure 2-69 shows sample debug ip igrp events output.
Figure 2-69 Sample Debug IP IGRP Events Output
Figure 2-69 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.
The first line 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)
ip-address (Optional) IP address of an IGRP neighbor.
router# debug ip igrp events
IGRP: Update contains 26 interior, 40 system, and 3 exterior routes.
IGRP: Total routes in update: 69
IGRP: received update from 160.89.32.24 on Ethernet0
IGRP: received update from 160.89.32.7 on Ethernet0
Updates sent
to these two
destination
addresses
Updates
received from
these source
addresses
S
2
5
4
8
The second line summarizes the number and types of routes described in the update:
The third line indicates the total number of routes described in the update.
debug ip igrp transaction
Use the debug ip igrp transaction EXEC command to display transaction information on Interior
Gateway Routing Protocol (IGRP) routing transactions. The no form of this command disables
debugging output.
debug ip igrp transaction [ip-address]
no debug ip igrp transaction [ip-address]
Syntax Description
Command Mode
EXEC
Usage Guidelines
If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp transaction output
includes 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 transaction can flood the
console and make the router unusable. In this case, use debug ip igrp events instead to display
summary routing information.
Sample Display
Figure 2-70 shows sample debug ip igrp transaction output.
Figure 2-70 Sample Debug IP IGRP Transaction Output
ip-address (Optional) IP address of an IGRP neighbor.
Router# debug ip igrp transactions
IGRP: received update from 160.89.80.240 on Ethernet
subnet 160.89.66.0, metric 1300 (neighbor 1200)
network 192.82.152.0, metric 158550 (neighbor 158450)
network 192.68.151.0, metric 1115511 (neighbor 1115411)
network 150.136.0.0, metric 16777215 (inaccessible)
exterior network 129.140.0.0, metric 9676 (neighbor 9576)
exterior network 140.222.0.0, metric 9676 (neighbor 9576)
IGRP: received update from 160.89.80.28 on Ethernet
subnet 160.89.15.0, metric 16777215 (inaccessible)
subnet 160.89.94.0, metric=847
IGRP: sending update to 255.255.255.255 via Serial1 (160.89.94.31)
subnet 160.89.80.0, metric=16777215
subnet 160.89.64.0, metric=1100
Updates sent
o these two
ource
addresses
Updates
eceived from
hese two
destination
addresses
S
2
5
4
9
Figure 2-70 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 ten 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 updatesin both cases to the broadcast address
255.255.255.255 as the destination address.
The first line in Figure 2-70 is self-explanatory.
On the second line in Figure 2-70, 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 2-70 show that the router is sending updates that 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 transaction 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
Use the debug ip mpacket EXEC command to display only IP multicast packets received and
transmitted.The no form of this command disables debugging output.
debug ip mpacket [group]
no debug ip mpacket [group]
Syntax Description
Command Mode
EXEC
group (Optional) Group name or address to monitor a single
groups packet activity.
Usage Guidelines
This command displays information for multicast IP packets that are forwarded from this router. By
using the optional group, you can limit the display to a specific multicast group.
Use this command with debug ip packet to observe additional packet information.
Note The debug ip mpacket command generates lots of messages. Use with care so that
performance on the network is not affected by the debug message traffic.
Sample Display
Figure 2-71 shows sample debug ip mpacket output.
Figure 2-71 Sample Debug IP Mpacket Output
router# debug ip mpacket 224.2.0.1
IP: s=131.188.34.54 (Ethernet1), d=224.2.0.1 (Tunnel0), len 88, mforward
Table 2-39 defines fields shown in Figure 2-71.
Table 2-39 Debug IP Mpacket Field Descriptions
Related Commands
debug ip dvmrp
debug ip igmp
debug ip mrouting
debug ip packet
debug ip sd
Field Description
IP An IP packet.
s= address The source address of the packet.
(Ethernet1) The name of the interface that received the packet.
d= address The multicast group address that is the destination for this packet.
(Tunnel0) The outgoing interface for the packet.
len 88 The number of bytes in the packet. This value will vary depending on the
application and the media.
mforward The packet has been forwarded.
not RPF interface The interface is not a reverse packet forwarding interface. (See debug ip
mrouting.)
RPF lookup failed The reverse packet forwarding lookup failed. (See debug ip mrouting.)
debug ip mcache
debug ip mcache
Use the debug ip mcache command to display IP multicast fast-switching events. The no form of
this command disables debugging output.
debug ip mcache [name | address]
no debug ip mcache
Syntax Description
Command Mode
EXEC
Usage Guidelines
Use this command when multicast fast-switching appears not to be functioning.
Sample Display
Figure 2-72 shows sample debug ip mcache output when an IP multicast route is cleared.
Figure 2-72 Sample Debug IP Mcache Output
router# debug ip mcache
IP multicast fast-switching debugging is on
router#clear ip mroute *
MRC: Build MAC header for (171.69.60.185/32, 224.2.231.173), Ethernet0
MRC: Fast-switch flag for (171.69.60.185/32, 224.2.231.173), off -> on, caller
ip_mroute_replicate-1
Table 2-40 provides explanations for representative lines of the debug ip mcache output shown in
Figure 2-72.
Table 2-40 Debug IP Mcache Descriptions
Field Description
MRC Multicast route cache.
Fast-switch flag Route is fast-switched.
(address/32) Host route with 32 bits of mask.
off -> on State has changed.
caller string The code function that activated the state change.
debug ip mcache
Related Commands
debug ip dvmrp
debug ip igmp
debug ip mrouting
debug ip sd
debug ip mrouting
debug ip mrouting
Use the debug ip mrouting EXEC command to display changes to the IP multicast routing table.
debug ip mrouting [group]
no debug ip mrouting [group]
Syntax Description
Command Mode
EXEC
Usage Notes
This command tells when the router has made changes to the mroute table. Use the debug ip pim
and debug ip mrouting commands at the same time to obtain additional multicast routing
information. In addition, use the debug ip igmp command to see why an mroute message is being
displayed.
This command generates a large amount of output. Use the optional group to limit the output to a
single multicast group.
Sample Display
Figure 2-73 shows sample debug ip mrouting output.
Figure 2-73 Sample Debug IP Mrouting Output
router# debug ip mrouting 224.2.0.1
IP multicast routing debugging is on
MRT: Delete (13.0.0.0/8, 224.2.0.1)
MRT: Delete (128.3.0.0/16, 224.2.0.1)
MRT: Delete (128.6.0.0/16, 224.2.0.1)
MRT: Delete (128.9.0.0/16, 224.2.0.1)
MRT: Delete (128.16.0.0/16, 224.2.0.1)
MRT: Create (*, 224.2.0.1), if_input NULL
MRT: Create (198.92.15.0/24, 225.2.2.4), if_input Ethernet0, RPF nbr 131.108.61.15
The following lines show that multicast IP routes were deleted from the routing table:
MRT: Delete (13.0.0.0/8, 224.2.0.1)
MRT: Delete (128.3.0.0/16, 224.2.0.1)
MRT: Delete (128.6.0.0/16, 224.2.0.1)
debug ip mrouting
The *,G entry in the following line is always null since it is a *,G. The *,G entries are generally
created by receipt of an IGMP host-report from a group member on the directly connected lan or by
a PIM join message (in sparse mode) which this router receives from a router that is sending joins
toward the RP. This router will in turn, send a join toward the RP which creates the shared tree (or
RP tree).
MRT: Create (*, 224.2.0.1), if_input NULL
The following lines are an example of creating an S,G entry that show a mpacket was received on
E0. The second line shows a route being created for a source that is on a directly connected LAN.
The RPF means reverse path forwarding, whereby the router looks up the source address of the
multicast packet in the unicast routing table and asks which interface will be used to send a packet
to that source.
The following lines show that multicast IP routes were added to the routing table. Note the 0.0.0.0
as the RPF, which means the route was created by a source that is directly connected to this router.
If the source is not directly connected, the nbr address shown in these lines will be the address of the
router that forwarded the packet to this router.
The shortest path tree state maintained in routers consists of source (S), multicast address (G),
outgoing interface (OIF), and incoming interface (IIF). The forwarding information is referred to as
the multicast forwarding entry for (S,G).
An entry for a shared tree can match packets from any source for its associated group if the packets
come through the proper incoming interface as determined by the RPF lookup. Such an entry is
denoted as (*,G). A (*,G) entry keeps the same information a (S,G) entry keeps, except that it saves
the rendezvous point (RP) address in place of the source address in sparse mode or 0.0.0.0 in dense
mode.
Related Commands
debug ip dvmrp
debug ip igmp
debug ip pim
debug ip packet
debug ip sd
debug ip ospf events
Use the debug ip ospf events EXEC command to display information on Open Shortest Path First
(OSPF)-related events, such as adjacencies, flooding information, designated router selection, and
shortest path first (SPF) calculation. The no form of this command disables debugging output.
no debug ip ospf events
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-74 shows sample debug ip ospf events output.
Figure 2-74 Sample Debug IP OSPF Events Output
router# debug ip ospf-events
OSPF:hello with invalid timers on interface Ethernet0
hello interval received 10 configured 10
net mask received 255.255.255.0 configured 255.255.255.0
dead interval received 40 configured 30
The debug ip ospf events output shown in Figure 2-74 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 both neighbors are part of the same area type.
In the following example line, the neighbor and this router are not part of a stub area (that is, one is
a part of a transit area and the other is a part of a stub area, as explained in RFC 1247).
OSPF: hello packet with mismatched E bit
Related Command
debug ip ospf packet
Use the debug ip ospf packet EXEC command to display information about each Open Shortest
Path First (OSPF) packet received. The no form of this command disables debugging output.
[no] debug ip ospf packet
Sample Display
Figure 2-75 shows sample debug ip ospf packet output.
Figure 2-75 Sample Debug IP OSPF Packet Output
router# debug ip ospf packet
OSPF: rcv. v:2 t:1 l:48 rid:200.0.0.117
aid:0.0.0.0 chk:6AB2 aut:0 auk:
The debug ip ospf packet command produces one set of information for each packet received. The
output varies slightly depending on which authentication is used. Figure 2-76 shows sample debug
ip ospf packet output when MD5 authentication is used.
Figure 2-76 Sample Debug IP OSPF Packet OutputMD5 Authentication
router# debug ip ospf packet
OSPF: rcv. v:2 t:1 l:48 rid:200.0.0.116
aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x0
Table 2-41 describes the fields shown in Figure 2-75 and Figure 2-76.

Table 2-41 Debug IP OSPF Packet Field Descriptions
Field Description
v: OSPF version.
t: OSPF packet type. Possible packet types follow:
1Hello
2Data description
3Link state request
4Link state update
5Link state acknowledgment
l: OSPF packet length in bytes.
rid: OSPF router ID.
aid: OSPF area ID.
chk: OSPF checksum.
aut: OSPF authentication type. Possible authentication types follow:
0No authentication
1Simple password
2MD5
Related Command
auk: OSPF authentication key.
keyid: MD5 key ID.
seq: Sequence number.
Table 2-41 Debug IP OSPF Packet Field Descriptions (Continued)
Field Description
debug ip packet
debug ip packet
Use the debug ip packet EXEC command to display general IP debugging information and IP
security option (IPSO) security transactions. The no form of this command disables debugging
output.
debug ip packet [access-list-number]
no debug ip packet [access-list-number]
Syntax Description
Command Mode
EXEC
Usage Guidelines
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 is also sent to the sending host when the router
configuration allows it.
Note Because the debug ip packet command generates a significant amount of output, use it only
when traffic on the IP network is low, so other activity on the system is not adversely affected.
access-list-number (Optional) IP access list number that you can specify. If the
datagram is not permitted by that access list, the related
debugging output is suppressed.
debug ip packet
Sample Display
Figure 2-77 shows sample debug ip packet output.
Figure 2-77 Sample Debug IP Packet Output
router# debug ip packet
IP: s=131.108.13.44 (Fddi0), d=157.125.254.1 (Serial2), g=131.108.16.2, forward
IP: s=131.108.1.57 (Ethernet4), d=192.36.125.2 (Serial2), g=131.108.16.2, forward
IP: s=131.108.1.6 (Ethernet4), d=255.255.255.255, rcvd 2
IP: s=131.108.1.55 (Ethernet4), d=131.108.2.42 (Fddi0), g=131.108.13.6, forward
IP: s=131.108.89.33 (Ethernet2), d=131.130.2.156 (Serial2), g=131.108.16.2, forward
IP: s=131.108.20.32 (Ethernet2), d=255.255.255.255, rcvd 2
IP: s=131.108.1.57 (Ethernet4), d=192.36.125.2 (Serial2), g=131.108.16.2, access denied
Figure 2-77 shows two types of messages that the debug ip packet command 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 2-42 describes the fields shown in the first line of Figure 2-77.
Table 2-42 Debug IP Packet Field Descriptions
The calculation on whether to send a 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, assume it
to be correct. If there is something wrong, the datagram is treated as unclassified genser. Then the
label is compared with the interface range, and the appropriate action is taken as Table 2-43
describes.
Table 2-43 Security Actions
Field Description
IP: Indicates that this is an IP packet.
s = 131.108.13.44 (Fddi0) Indicates the source address of the packet and the name of the interface
that received the packet.
d = 157.125.254.1 (Serial2) Indicates the destination address of the packet and the name of the
interface (in this case, S2) through which the packet is being sent out on
the network.
g = 131.108.16.2 Indicates the address of the next hop gateway.
forward Indicates that the router is forwarding the packet. If a filter denies a
packet, access denied replaces forward, as shown in the last line of
output in Figure 2-77.
Classification Authorities Action Taken
Too low Too low
Good
Too high
No Response
No Response
No Response
debug ip packet
The security code can only generate a few types of ICMP error messages. The only possible error
messages and their meanings follow:
ICMP Parameter problem, code 0Error at pointer
ICMP Parameter problem, code 1Missing option
ICMP Parameter problem, code 2See Note that follows
ICMP Unreachable, code 10Administratively prohibited
Note The message ICMP Parameter problem, code 2 identifies a specific error that occurs in the
processing of a datagram. This message indicates that the router received a datagram containing a
maximum length IP header but no security option. After being processed and routed to another
interface, it is discovered that the outgoing interface is marked with add a security label. Since the
IP header is already full, the system cannot add a label and must drop the datagram and return an
error message.
When an IP packet is rejected due to an IP security failure, an audit message is sent via DNSIX NAT.
Also, any debug ip packet output is appended to include a description of the reason for rejection.
This description can be any of the following:
No basic
No basic, no response
Reserved class
Reserved class, no response
Class too low, no response
Class too high
Class too high, bad authorities, no response
Unrecognized class
Unrecognized class, no response
Multiple basic
Multiple basic, no response
Authority too low, no response
Authority too high
Compartment bits not dominated by maximum sensitivity level
In range Too low
Good
Too high
No Response
Accept
Send Error
Too high Too low
In range
Too high
No Response
Send Error
Send Error
Classification Authorities Action Taken
debug ip packet
Compartment bits do not dominate minimum sensitivity level
Security failure: extended security disallowed
NLESO source appeared twice
ESO source not found
Postroute, failed xfc out
No room to add IPSO
debug ip pim
debug ip pim
Use the debug ip pim EXEC command to display Protocol Independent Multicast (PIM) packets
received and transmitted as well as PIM related events.The no form of this command disables
debugging output.
debug ip pim [group]
no debug ip pim [group]
Syntax Description
Command Mode
EXEC
Usage Guidelines
PIM uses IGMP packets to communicate between routers and advertise reachability information.
Use this command with debug ip igmp and debug ip mrouting to observe additional multicast
routing information.
Sample Display
Figure 2-78 shows sample debug ip pim output.
Figure 2-78 Sample Debug IP PIM Output
router# debug ip pim 224.2.0.1
PIM: Received Join/Prune on Ethernet1 from 198.92.37.33
PIM: Received Join/Prune on Tunnel0 from 10.3.84.1
PIM: Received RP-Reachable on Ethernet1 from 131.108.20.31
PIM: Update RP expiration timer for 224.2.0.1
PIM: Forward RP-reachability packet for 224.2.0.1 on Tunnel0
PIM: Prune-list (163.221.196.51/32, 224.2.0.1)
PIM: Set join delay timer to 2 seconds for (163.221.0.0/16, 224.2.0.1) on Ethernet1
PIM: Received Join/Prune on Tunnel0 from 10.3.84.1
PIM: Join-list: (*, 224.2.0.1) RP 131.108.20.31
PIM: Add Tunnel0 to (*, 224.2.0.1), Forward state
PIM: Join-list: (13.0.0.0/8, 224.2.0.1)
PIM: Add Tunnel0 to (13.0.0.0/8, 224.2.0.1), Forward state
PIM: Join-list: (128.3.0.0/16, 224.2.0.1)
PIM: Prune-list (198.92.84.16/28, 224.2.0.1) RP-bit set RP 198.92.84.16
PIM: Send Prune on Ethernet1 to 198.92.37.6 for (198.92.84.16/28, 224.2.0.1), RP
PIM: For RP, Prune-list: 128.9.0.0/16
debug ip pim
PIM: For 10.3.84.1, Join-list: 198.92.84.16/28
PIM: Send periodic Join/Prune to RP via 198.92.37.6 (Ethernet1)
The following lines appear periodically when PIM is running in sparse mode and indicate to this
router which multicast groups and multicast sources other routers are interested in:
The following lines appear when a rendezvous point (RP) message is received and the RP timer is
reset. The expiration timer sets a checkpoint to make sure the RP still exists; otherwise a new RP
must be discovered:
PIM: Received RP-Reachable on Ethernet1 from 131.108.20.31
PIM: Update RP expiration timer for 224.2.0.1
PIM: Forward RP-reachability packet for 224.2.0.1 on Tunnel0
The prune-list message in the following line states that this router is not interested in the source
address information. The prune message tells an upstream router to stop forwarding multicast
packets from this source.
PIM: Prune-list (163.221.196.51/32, 224.2.0.1)
In the following line, a second router on the network wants to override the prune message that the
upstream router just received. The timer is set at a random value so that if there are additional routers
on the network that still want to receive multicast packets for the group, only one will actually send
the message. The other routers will receive the join message and then suppress sending their own
message.
PIM: Set join delay timer to 2 seconds for (163.221.0.0/16, 224.2.0.1) on Ethernet1
In the following line, a join message is sent towards the RP for all sources:
PIM: Join-list: (*, 224.2.0.1) RP 131.108.20.31
In the following lines, the interface is being added to the outgoing interface (OIF) of the *,G and S,G
mroute table entry so that packets from the source will be forwarded out that particular interface:
PIM: Add Tunnel0 to (*, 224.2.0.1), Forward state
PIM: Add Tunnel0 to (13.0.0.0/8, 224.2.0.1), Forward state
The following line appears in sparse mode only. There are two trees on which data may be received:
the RP tree and the source tree. In dense mode there is no RP. After the source and the receiver have
discovered one another at the RP, the first-hop router for the receiver will usually join to the source
tree rather than the RP tree:
PIM: Prune-list (198.92.84.16/28, 224.2.0.1) RP-bit set RP 198.92.84.16
The Send Prune message in the next line shows that a router is sending a message to a second router
saying that the first router no longer wants to receive multicast packets for the S,G. The RP at the
end of the message indicates that the router is pruning the RP tree and is most likely joining the
source tree, although the router may not have downstream members for the group or downstream
routers with members of the group. The output shows which specific sources this router no longer
wants to receive multicast from.
PIM: Send Prune on Ethernet1 to 198.92.37.6 for (198.92.84.16/28, 224.2.0.1), RP
debug ip pim
The following lines indicate a prune message is sent toward the RP so that router can join the source
tree rather than the RP tree:
In the following line, a periodic message is sent towards the RP. The default period is once per
minute. Prune and join messages are sent toward the RP or source rather than directly to the RP or
source. It is the responsibility of the next-hop router to take proper action with this message, such as
continuing to forward it to the next router in the tree.
PIM: Send periodic Join/Prune to RP via 198.92.37.6 (Ethernet1)
Related Commands
debug ip dvmrp
debug ip igmp
debug ip mrouting
debug ip sd
debug ip rip
debug ip rip
Use the debug ip rip EXEC command to display information on RIP routing transactions. The no
debug ip rip
no debug ip rip
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-79 shows sample debug ip rip output.
Figure 2-79 Sample Debug IP RIP Output
Figure 2-79 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 update131.108.0.0is 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 broadcast address 255.255.255.255 as the destination.
The first line in Figure 2-79 is self-explanatory.
The second line in Figure 2-79 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 2-79 show that the router is sending updates that 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.
router# debug ip rip
RIP: received update from 10.89.80.28 on Ethernet0
10.89.95.0 in 1 hops
10.89.81.0 in 1 hops
10.89.66.0 in 2 hops
172.31.0.0 in 16 hops (inaccessible)
0.0.0.0 in 7 hop
RIP: sending update to 255.255.255.255 via Ethernet0 (10.89.64.31)
subnet 10.89.94.0, metric 1
RIP: sending update to 255.255.255.255 via Serial1 (10.89.94.31)
default 0.0.0.0, metric 8
pdates
eceived
om this
ource
ddress
pdates
ent to
hese two
estination
ddresses
S
2
5
5
0
debug ip rip
Entries such as the following appear at startup or when an event occurs such as an interface
transitioning or a 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 routing
debug ip routing
Use the debug ip routing EXEC command to display information on Routing Information Protocol
(RIP) routing table updates and route-cache updates. The no form of this command disables
debugging output.
debug ip routing
no debug ip routing
Syntax Description
Command Mode
EXEC
Sample Display
Figure 2-80 shows sample debug ip routing output.
Figure 2-80 Sample Debug IP Routing Output
router# debug ip routing
RT: add 198.93.168.0 255.255.255.0 via 198.92.76.30, igrp metric [100/3020]
RT: metric change to 198.93.168.0 via 198.92.76.30, igrp metric [100/3020]
new metric [100/2930]
IP: cache invalidation from 0x115248 0x1378A, new version 5736
RT: delete route to 198.133.219.0 via 198.92.76.30, igrp metric [100/10816]
RT: no routes to 198.133.219.0, entering holddown
RT: 198.133.219.0 came out of holddown
RT: garbage collecting entry for 198.133.219.0
RT: garbage collecting entry for 198.133.219.0
In the following lines, a newly created entry has been added to the IP routing table. The metric
change indicates that this entry existed previously, but its metric changed and the change was
reported by means of IGRP. The metric could also be reported via RIP, OSPF, or another IP routing
protocol. The numbers inside the brackets report the administrative distance and the actual metric.
debug ip routing
Cache invalidation means that the fast switching cache was invalidated due to a routing table
change. New version is the version number of the routing table. When the routing table changes,
this number is incremented. The hexadecimal numbers are internal numbers that vary from version
to version and software load to software load.
In the following output, the holddown and cache invalidation lines are displayed. Most of the
distance vector routing protocols use holddown to avoid typical problems like counting to infinity
and routing loops. If you look at the output of show ip protocols you will see what the timer values
are for holddown and cache invalidation. Cache invalidation corresponds to came out of
holddown. Delete route is triggered when a better path comes along. It gets rid of the old inferior
path.
debug ip sd
debug ip sd
Use the debug ip sd command to display all session directory (SD) announcements received. The
debug ip sd
no debug ip sd
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command shows session directory announcements for multicast IP. Use it to observe multicast
activity.
Sample Display
Figure 2-81 shows sample debug ip sd output.
Figure 2-81 Sample Debug IP SD Output
router# debug ip sd
SD: Announcement from 171.69.58.81 on Serial0.1, 146 bytes
s=*cisco: CBONE Audio
i=cisco internal-only audio conference
o=dino@dino-ss20.cisco.com
c=224.0.255.1 16 2891478496 2892688096
m=audio 31372 1700
SD: Announcement from 204.62.246.68 on Serial0.1, 147 bytes
s=IMS: U.S. Senate
i=U.S. Senate at http://town.hall.org/radio/live.html
o=carl@also.radio.com
c=224.2.252.231 95 0 0
m=audio 36572 2642
a=fmt:gsm
Table 2-44 provides explanations for representative lines of the debug ip sd output shown in
Figure 2-81.
Table 2-44 Debug IP SD Output Descriptions
Field Description
SD Session directory event.
Announcement from Address sending the SD announcement.
on Serial0.1 Interface receiving the announcement.
146 bytes Size of the announcement event.
debug ip sd
Related Commands
debug ip dvmrp
debug ip igmp
debug ip mcache
debug ip mrouting
debug ip pim
s= Session name being advertised.
i= Information providing a descriptive name for the session.
o= Origin of the session, either an IP address or a name.
c= Connect description showing address and number of hops.
m= Media description that includes media type, port number, and ID.
Field Description
debug ip security
debug ip security
Use the debug ip security EXEC command to display IP security option processing. The no form
debug ip security
no debug ip security
Syntax Description
Command Mode
EXEC
Usage Guidelines
The debug ip security command displays information for both basic and extended IP security
options. For interfaces where ip security is configured, each IP packet processed for that interface
results in debugging output regardless of whether the packet contains IP security options. IP packets
processed for other interfaces that also contain IP security information also trigger debugging
output. Some additional IP security debugging information is also controlled by the debug ip packet
EXEC command.
Note Because the debug ip security command generates a significant amount of output for every
IP packet processed, use it only when traffic on the IP network is low, so other activity on the system
is not adversely affected.
Sample Display
Figure 2-82 shows sample debug ip security output.
Figure 2-82 Sample Debug IP Security Output
router# debug ip security
IP Security: src 198.92.72.52 dst 198.92.72.53, number of BSO 1
idb: NULL
pak: insert (0xFF) 0x0
IP Security: BSO postroute: SECINSERT changed to secret (0x5A) 0x10
IP Security: src 198.92.72.53 dst 198.92.72.52, number of BSO 1
idb: secret (0x6) 0x10 to secret (0x6) 0x10, no implicit
def secret (0x6) 0x10
pak: secret (0x5A) 0x10
IP Security: checking BSO 0x10 against [0x10 0x10]
IP Security: classified BSO as secret (0x5A) 0x10
debug ip security
Table 2-45 Debug IP Security Field Descriptions
The following line indicates that the packet was locally generated, and it has been classified with the
internally significant security level insert (0xff) and authority 0x0:
idb: NULL
pak: insert (0xff) 0x0
The following line indicates that the packet was received via an interface with dedicated IP security
configured. Specifically, the interface is configured at security level secret and with authority
information of 0x0. The packet itself was classified at level secret (0x5a) and authority 0x10.
idb: secret (0x6) 0x10 to secret (0x6) 0x10, no implicit
def secret (0x6) 0x10
pak: secret (0x5A) 0x10
Field Description
number of BSO Indicates the number of basic security options found in the packet.
idb Provides information on the security configuration for the incoming interface.
pak Provides information on the security classification of the incoming packet.
src Indicates the source IP address.
dst Indicates the destination IP address.
debug ip tcp driver
debug ip tcp driver
Use the debug ip tcp driver EXEC command to display information on Transmission Control
Protocol (TCP) driver events; for example, connections opening or closing, or packets being dropped
because of full queues. The no form of this command disables debugging output.
debug ip tcp driver
no debug ip tcp driver
Syntax Description
Command Mode
EXEC
Usage Guidelines
The TCP driver is the process that the router software uses to send packet data over a TCP
connection. Remote source-route bridging, STUN (serial tunneling), and X.25 switching currently
use the TCP driver.
Using the debug ip tcp driver command together with the debug ip tcp driver-pak command
provides the most verbose debugging output concerning TCP driver activity.
Sample Display
Figure 2-83 shows sample debug ip tcp driver output.
Figure 2-83 Sample Debug IP TCP Driver Output
router# debug ip tcp driver
TCPDRV359CD8: Active open 160.89.80.26:0 --> 160.89.80.25:1996 OK, lport 36628
TCPDRV359CD8: enable tcp timeouts
TCPDRV359CD8: 160.89.80.26:36628 --> 160.89.80.25:1996 Abort
TCPDRV359CD8: 160.89.80.26:36628 --> 160.89.80.25:1996 DoClose tcp abort
Table 2-46 describes the fields in the first line of output.
Table 2-46 Debug IP TCP Driver Field Descriptions
Field Description
TCPDRV359CD8: Unique identifier for this instance of TCP driver activity.
Active open 160.89.80.26 Indication that the router at IP address 160.89.80.26 has initiated a
connection to another router.
:0 The TCP port number the initiator of the connection uses to indicate that
any port number can be used to set up a connection.
--> 160.89.80.25 The IP address of the remote router to which the connection has been
initiated.
debug ip tcp driver
The following line indicates that the TCP driver user (remote source-route bridging, in this case) will
allow TCP to drop the connection if excessive retransmissions occur:
TCPDRV359CD8: enable tcp timeouts
The following line indicates that the TCP driver user (in this case, remote source-route bridging) at
IP address 160.89.80.26 (and using TCP port number 36628) is requesting that the connection to IP
address 160.89.80.25 using TCP port number 1996 be aborted:
TCPDRV359CD8: 160.89.80.26:36628 --> 160.89.80.25:1996 Abort
The following line indicates that this connection was in fact closed due to an abort:
TCPDRV359CD8: 160.89.80.26:36628 --> 160.89.80.25:1996 DoClose tcp abort
:1996 The TCP port number that the initiator of the connection is requesting
that the remote router use for the connection. (1996 is a private TCP port
number reserved in this implementation for remote source-route
bridging.)
OK, Indication that the connection has been established. If the connection has
not been established, this field and the following field do not appear in
this line of output.
lport 36628 The TCP port number that has actually been assigned for the initiator to
use for this connection.
Field Description
debug ip tcp driver-pak
Use the debug ip tcp driver-pak EXEC command to display information on every operation that
the Transmission Control Protocol (TCP) driver performs. The no form of this command disables
debugging output.
no debug ip tcp driver-pak
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command turns on a verbose debugging by logging at least one debugging message for every
packet sent or received on the TCP driver connection.
The TCP driver is the process that the router software uses to send packet data over a TCP
connection. Remote source-route bridging, STUN (serial tunneling), and X.25 switching currently
use the TCP driver.
To observe the context within which certain debug ip tcp driver-pak messages occur, turn on this
command in conjunction with the debug ip tcp driver command.
Note Because the debug ip tcp driver-pak command generates so many messages, use it only on
lightly loaded systems. This command not only places a significant load on the system processor,
but it may even change the symptoms of any unexpected behavior that occur.
Sample Display
Figure 2-84 shows sample debug ip tcp driver-pak output.
Figure 2-84 Sample Debug IP TCP Driver-Pak Output
router# debug ip tcp driver-pak
TCPDRV359CD8: send 2E8CD8 (len 26) queued
TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
TCPDRV359CD8: readf 42 bytes (Thresh 16)
TCPDRV359CD8: send 327E40 (len 4502) queued
TCPDRV359CD8: output pak 327E40 (len 4502) (4502)
Table 2-47 describes the fields shown in the first line of output.
Table 2-47 Debug TCP Driver-Pak Field Descriptions
The following line indicates that the TCP driver has sent the data that it had received from the TCP
driver user, as shown in the previous line of output. The last field in the line (26) indicates that the
26 bytes of data were sent out as a single unit.
TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
The following line indicates that the TCP driver has received 42 bytes of data from the remote IP
address. The TCP driver user (in this case, remote source-route bridging) has established an input
threshold of 16 bytes for this connection. (The input threshold instructs the TCP driver to transfer
data to the TCP driver user only when at least 16 bytes are present.)
Field Description
TCPDRV359CD8 Unique identifier for this instance of TCP driver activity.
send Indication that this event involves the TCP driver sending data.
2E8CD8 Address in memory of the data the TCP driver is sending.
(len 26) Length of the data (in bytes).
queued Indication that the TCP driver user process (in this case, remote
source-route bridging) has transferred the data to the TCP driver to send.
debug ip tcp transactions
Use the debug ip tcp transactions EXEC command to display information on significant
Transmission Control Protocol (TCP) transactions such as state changes, retransmissions, and
duplicate packets. The no form of this command disables debugging output.
no debug ip tcp transactions
Syntax Description
Command Mode
EXEC
Usage Guidelines
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 transactions command displays output for packets the router sends and receives,
but does not display output for packets it forwards.
Sample Display
Figure 2-85 shows sample debug ip tcp transactions output.
Figure 2-85 Sample Debug IP TCP Output
router# debug ip tcp transactions
TCP: sending SYN, seq 168108, ack 88655553
TCP0: Connection to 26.9.0.13:22530, advertising MSS 966
TCP0: state was LISTEN -> SYNRCVD [23 -> 26.9.0.13(22530)]
TCP0: state was SYNSENT -> SYNRCVD [23 -> 26.9.0.13(22530)]
TCP0: Connection to 26.9.0.13:22530, received MSS 956
TCP0: restart retransmission in 5996
TCP0: state was SYNRCVD -> ESTAB [23 -> 26.9.0.13(22530)]
TCP2: restart retransmission in 13384 -> 26.0.0.13(16151)]
TCP0: restart retransmission in 5996 [23 -> 26.0.0.13(16151)]
Table 2-48 Debug IP TCP Field Descriptions
Field Description
TCP: Indicates that this is a TCP transaction.
sending SYN Indicates that a synchronize packet is being sent.
seq 168108 Indicates the sequence number of the data being sent.
ack 88655553 Indicates the sequence number of the data being
acknowledged.
TCP0: Indicates the TTY number (0, in this case) with which this
TCP connection is associated.
Connection to 26.9.0.13:22530 Indicates the remote address with which a connection has
been established.
advertising MSS 966 Indicates the maximum segment size this side of the TCP
connection is offering to the other side.
state was LISTEN -> SYNSENT Indicates that the TCP state machine changed state from
LISTEN to SYNSENT. Possible TCP states follow:
CLOSEDConnection closed.
CLOSEWAITReceived a FIN segment.
CLOSINGReceived a FIN/ACK segment.
ESTABConnection established.
FINWAIT 1Sent a FIN segment to start closing the
connection.
FINWAIT 2Waiting for a FIN segment.
LASTACKSent a FIN segment in response to a received
FIN segment.
LISTENListening for a connection request.
SYNRCVDReceived a SYN segment, and responded.
SYNSENTSent a SYN segment to start connection
negotiation.
TIMEWAITWaiting for network to clear segments for this
connection before the network no longer recognizes the
connection as valid. This must occur before a new connection
can be set up.
[23 -> 26.9.0.13(22530)] Within these brackets:
The first field (23) indicates local TCP port.
The second field (26.9.0.13) indicates the destination IP
address.
The third field (22530) indicates the destination TCP port.
restart retransmission in 5996 Indicates the number of milliseconds until the next
retransmission takes place.
Field Description

Dapple

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Dapple

Caricato da

Copyright:

Formati disponibili

C H A P T E R

Debug Commands 2-1

Potrebbero piacerti anche