Table Of Contents
debug frame-relay informationelements
debug frame-relay networklayerinterface
Debug Commands
This chapter contains an alphabetical listing of the debug commands and their descriptions. 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 commands 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 debug command output is documented also varies. For example, the output for debug commands that generate lines of text is usually described line by line, and the output for debug commands that generate information in field format is usually described in tables.
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.
debug aaa accounting
Use the debug aaa accounting EXEC command to display information on accountable events as they occur. Use the no form of the command to disable debugging output.
[no] debug aaa accounting
Usage Guidelines
The information displayed by the debug aaa accounting command is independent of the accounting protocol used to transfer the accounting information to a server. Use the debug tacacs and debug radius protocol specific commands to get more detailed information about protocol-level issues.
You can also use the show accounting command to step through all active sessions and to print all the accounting records for actively accounted functions. The show accounting command allows you to display the active "accountable events" on the system. It provides systems administrators a quick look at what is going on, and may also be useful for collecting information in the event of a data loss of some kind on the accounting server. The show accounting command displays additional data on the internal state of the Authentication, Authorization, and Accounting (AAA) security system if debug aaa accounting is turned on as well.
Sample Display
shows sample output from the debug aaa accounting command.
Figure 2-1 Sample Debug AAA Accounting Output
router# debug aaa accountingAAA Accounting debugging is on16:49:21: AAA/ACCT: EXEC acct start, line 1016:49:32: AAA/ACCT: Connect start, line 10, glare16:49:47: AAA/ACCT: Connection acct stop:task_id=70 service=exec port=10 protocol=telnet address=172.31.3.78 cmd=glare bytes_in=308 bytes_out=76 paks_in=45 paks_out=54 elapsed_time=14Related Commands
debug aaa authentication
debug aaa authorization
debug radius
debug tacacsdebug aaa authentication
Use the debug aaa authentication EXEC command to display information on AAA/Terminal Access Controller Access Control System Plus (TACACS+) authentication. Use the no form of the command to disable debugging output.
[no] debug aaa authentication
Usage Guidelines
Use this command to see what methods of authentication are being used and what the results of these methods are.
Sample Display
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 occurring concurrently.
Figure 2-2 Sample Debug AAA Authentication Output
router# debug aaa authentication6:50:12: AAA/AUTHEN: create_user user='' ruser='' port='tty19' rem_addr='172.31.60.15' authen_type=1 service=1 priv=16:50:12: AAA/AUTHEN/START (0): port='tty19' list='' action=LOGIN service=LOGIN6:50:12: AAA/AUTHEN/START (0): using "default" list6:50:12: AAA/AUTHEN/START (50996740): Method=TACACS+6:50:12: TAC+ (50996740): received authen response status = GETUSER6:50:12: AAA/AUTHEN (50996740): status = GETUSER6:50:15: AAA/AUTHEN/CONT (50996740): continue_login6:50:15: AAA/AUTHEN (50996740): status = GETUSER6:50:15: AAA/AUTHEN (50996740): Method=TACACS+6:50:15: TAC+: send AUTHEN/CONT packet6:50:15: TAC+ (50996740): received authen response status = GETPASS6:50:15: AAA/AUTHEN (50996740): status = GETPASS6:50:20: AAA/AUTHEN/CONT (50996740): continue_login6:50:20: AAA/AUTHEN (50996740): status = GETPASS6:50:20: AAA/AUTHEN (50996740): Method=TACACS+6:50:20: TAC+: send AUTHEN/CONT packet6:50:20: TAC+ (50996740): received authen response status = PASS6:50:20: AAA/AUTHEN (50996740): status = PASS
debug aaa authorization
Use the debug aaa authorization EXEC command to display information on AAA/TACACS+ authorization. Use the no form of the command to disable debugging output.
[no] debug aaa authorization
Usage Guidelines
Use this command to see what methods of authorization are being used and what the results of these methods are.
Sample Display
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-3 Sample Debug AAA Authorization Output
2:23:21: AAA/AUTHOR (0): user='carrel'2:23:21: AAA/AUTHOR (0): send AV service=shell2:23:21: AAA/AUTHOR (0): send AV cmd*2:23:21: AAA/AUTHOR (342885561): Method=TACACS+2:23:21: AAA/AUTHOR/TAC+ (342885561): user=carrel2:23:21: AAA/AUTHOR/TAC+ (342885561): send AV service=shell2:23:21: AAA/AUTHOR/TAC+ (342885561): send AV cmd*2:23:21: AAA/AUTHOR (342885561): Post authorization status = FAILThe 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
•
•
describes attribute value pairs associated with the aaa authorization command that may show up in the debug output.
Note
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.
[no] debug apple arp [type number]
Syntax Description
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
shows sample debug apple arp output.
Figure 2-4 Sample Debug Apple ARP Output
router# debug apple arpEther0: AARP: Sent resolve for 4160.26Ether0: 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)Ether0: AARP: Reply from 4160.19(0000.0c00.0082) for 4160.154(0000.0c00.8ea9)Ether0: AARP: Resolved waiting request for 4160.19(0000.0c00.0082)Ether0: AARP: Reply from 4160.19(0000.0c00.0082) for 4160.154(0000.0c00.8ea9)Explanations for representative lines of output in follow.
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.26The 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).
Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9)The following line indicates that the MAC address request is complete:
Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453)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.
[no] debug apple domain
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
shows sample debug apple domain output intermixed with output from the debug apple remap command; the two commands show related events.
Figure 2-5 Sample Debug Apple Domain Output
router# debug apple domainrouter# debug apple remapAT-REMAP: RemapProcess for net 30000 domain AURP Domain 1AT-REMAP: ReshuffleRemapList for subdomain 1AT-REMAP: Could not find a remap for cable 3000-3001AT-DOMAIN: atdomain_DisablePort for Tunnel0AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]AT-DOMAIN: Disabling interface Ethernet1AT-DOMAIN: atdomain_DisablePort for Ethernet1AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]AT-DOMAIN: CleanSubDomain for inbound subdomain 1AT-REMAP: Remap for net 70 inbound subdomain 1 has been deletedAT-DOMAIN: DeleteAvRemapList for inbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1AT-DOMAIN: CleanSubDomain for outbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1 Remaped Net 10000AT-REMAP: Remap for net 50 outbound subdomain 1 has been deletedAT-DOMAIN: DeleteAvRemapList for outbound subdomain 1AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]AT-DOMAIN: CleanSubDomain for inbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1AT-DOMAIN: CleanSubDomain for outbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1Related Command
debug apple eigrp-all
Use the debug apple eigrp-all EXEC command to enable debugging output from the Enhanced IGRP routines. The no form of this command disables debugging output.
[no] debug apple eigrp-all
Usage Guidelines
The debug apple eigrp-all command can be used to monitor acquisition of routes, aging route table entries, and advertisement of known routes through Enhanced IGRP.
CautionBecause the debug apple eigrp-all command can generate many messages, use it only when the router's CPU utilization is less than 50 percent.
Sample Display
shows sample debug apple eigrp-all output.
Figure 2-6 Sample Debug Apple EIGRP Output
router# debug apple eigrp-all3:54:34: atigrp2_router: peer is 83.1953:54:37: AT: atigrp2_write: about to send packet3:54:37: Ethernet2: output AT packet: enctype UNKNOWN, size 653:54:37: 07FFFFFF0000FFFFFFFFFFFF00000C1485B00046|0041ACD100000053FF8F585858020591103:54:37: 000000000000000000000000000000010001000C010001000000000F0204000C00530053003:54:37: AT: atigrp2, src=Ethernet2:83.143, dst=83-83, size=52, EIGRP pkt sent3:54:39: atigrp2_router: peer is 83.1953:54:42: AT: atigrp2_write: about to send packet3:54:42: Ethernet2: output AT packet: enctype UNKNOWN, size 653:54:42: 07FFFFFF0000FFFFFFFFFFFF00000C1485B00046|0041ACD100000053FF8F585858020591103:54:42: 000000000000000000000000000000010001000C010001000000000F0204000C00530053003:54:42: AT: atigrp2, src=Ethernet2:83.143, dst=83-83, size=52, EIGRP pkt sentdescribes the fields in the output shown in ,
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.
[no] debug apple errors [type number]
Syntax Description
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
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-7 Sample Debug Apple Errors Output
router# debug apple errors%AT-3-ZONEDISAGREES: Ethernet0: AppleTalk port disabled; zone list incompatible with 4160.19%AT-3-ZONEDISAGREES: Ethernet0: AppleTalk port disabled; zone list incompatible with 4160.19%AT-3-ZONEDISAGREES: Ethernet0: AppleTalk port disabled; zone list incompatible with 4160.19As 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.
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 encapsulationIn 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 availableAT: pak_reply: dubious reply creation, dst 4160.19AT: Unable to get a buffer for reply to 4160.19Processing error, src 4160.12-254,dst 4160.19-254,AEP, invalid echo packetThe 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 invalidIn 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 invalidIn 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 requestIn 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
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.
[no] debug apple events [type number]
Syntax Description
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
shows sample debug apple events output that describes a nonseed router coming up in discovery mode.
Figure 2-8 Sample Debug Apple Events Output—Discovery Mode State Changes
As 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
2
3
4
5
6
7
8
Explanations for individual lines of output in 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 filtersThe following messages indicate that the router is changing to restarting mode:
%AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restartedEther0: AppleTalk state changed; unknown -> restartingThe 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 -> probingThe 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.
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148The 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:
Ether0: AppleTalk state changed; probing -> acquiring%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configurationNow that the router has acquired the cable configuration information, the following message indicates that it restarts using that information:
Ether0: AppleTalk state changed; acquiring -> restartingThe following messages indicate that the router is probing for its actual network address:
Ether0: AppleTalk state changed; restarting -> line downEther0: AppleTalk state changed; line down -> restartingEther0: AppleTalk state changed; restarting -> probingThe following message indicates that the router has found an actual network address to use:
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 4160.148The 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:
Ether0: AppleTalk state changed; probing -> acquiring%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configurationThe following message indicates that the router is requesting the list of zones for its cable:
Ether0: AppleTalk state changed; acquiring -> requesting zonesThe 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 -> verifyingAT: Sent GetNetInfo request broadcast on Ethernet0The following message indicates that the router is rechecking its list of zones for its cable:
Ether0: AppleTalk state changed; verifying -> checking zonesThe following message indicates that the router is now fully operational as a routing node and can begin routing:
Ether0: AppleTalk state changed; checking zones -> operationalshows sample debug apple events output that describes a nondiscovery-enabled router coming up when no other router is on the wire.
Figure 2-9 Sample Debug Apple Events Output—Seed Coming Up by Itself
As 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 indicates this situation.
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-10 Sample Debug Apple Events Output—Nonseed with No Seed
router# debug apple eventsEther0: AT: Resetting interface address filters%AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restartedEther0: AppleTalk state changed; unknown -> restartingEther0: AppleTalk state changed; restarting -> probing%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148Ether0: AppleTalk state changed; probing -> acquiringAT: Sent GetNetInfo request broadcast on Ether0AT: Sent GetNetInfo request broadcast on Ether0AT: Sent GetNetInfo request broadcast on Ether0AT: Sent GetNetInfo request broadcast on Ether0AT: Sent GetNetInfo request broadcast on Ether0As 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.
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-11 Sample Debug Apple Events Output—Compatibility Conflict
The three configuration command lines that follow indicate the part of the router's configuration that caused the configuration mismatch shown in :
lestat(config)#int e 0lestat(config-if)#apple cab 41-41lestat(config-if)#apple zone MarketingThe router shown in 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 "Marketing."
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.
[no] debug apple nbp [type number]
Syntax Description
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
Sample Display
shows sample debug apple nbp output.
Figure 2-12 Sample Debug Apple NBP Output
router# debug apple nbpAT: NBP ctrl = LkUp, ntuples = 1, id = 77AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW LabAT: LkUp =:ciscoRouter@Low End SW LabAT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW LabAT: NBP ctrl = LkUp, ntuples = 1, id = 78AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW LabAT: NBP ctrl = LkUp, ntuples = 1, id = 79AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW LabAT: NBP ctrl = LkUp, ntuples = 1, id = 83AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW LabAT: LkUp =:ciscoRouter@Low End SW LabAT: NBP ctrl = LkUp, ntuples = 1, id = 84AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW LabAT: NBP ctrl = LkUp, ntuples = 1, id = 85AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW LabAT: NBP ctrl = LkUp, ntuples = 1, id = 85AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW LabThe first three lines in describe an NBP lookup request:
AT: NBP ctrl = LkUp, ntuples = 1, id = 77AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW LabAT: LkUp =:ciscoRouter@Low End SW Labdescribes the fields in the first line of output shown in .
describes the fields in the second line of output shown in .
The third line in 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 show the router's response:
AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW LabIn the first line, ctrl = LkUp-Reply identifies this NBP packet as an NBP lookup request. The same value in the id field (id = 77) associates this lookup reply with the previous lookup request. The second line indicates that the network address associated with the router's entity name (lestat.Ether0:ciscoRouter@Low End SW Lab) is 4160.154. The fact that no other entity name/network address is listed indicates that the responder only knows about itself as an object of type ciscoRouter in zone Low End SW Lab.
debug apple packet
Use the debug apple packet 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.
[no] debug apple packet [type number]
Syntax Description
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
Sample Display
shows sample debug apple packet output.
Figure 2-13 Sample Debug Apple Packet Output
router# debug apple packetEther0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000AT: src=Ethernet0:4160.47, dst=4160-4160, size=10, 2 rtes, RTMP pkt sentAT: ZIP Extended reply rcvd from 4160.19AT: ZIP Extended reply rcvd from 4160.19AT: src=Ethernet0:4160.47, dst=4160-4160, size=10, 2 rtes, RTMP pkt sentEther0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000Ether0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000describes the fields in the first line of output shown in .
describes the fields in the second line of output shown in .
The third line in indicates the type of packet received and its source AppleTalk address. This message is repeated in the fourth line because AppleTalk hosts can send multiple replies to a given GetNetInfo request.
debug apple 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.
[no] debug apple remap
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
shows sample debug apple remap output intermixed with output from the debug apple domain command; the two commands show related events.
Figure 2-14 Sample Debug Apple Remap and Domain Output
router# debug apple remaprouter# debug apple domainAT-REMAP: RemapProcess for net 30000 domain AURP Domain 1AT-REMAP: ReshuffleRemapList for subdomain 1AT-REMAP: Could not find a remap for cable 3000-3001AT-DOMAIN: atdomain_DisablePort for Tunnel0AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]AT-DOMAIN: Disabling interface Ethernet1AT-DOMAIN: atdomain_DisablePort for Ethernet1AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]AT-DOMAIN: CleanSubDomain for inbound subdomain 1AT-REMAP: Remap for net 70 inbound subdomain 1 has been deletedAT-DOMAIN: DeleteAvRemapList for inbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1AT-DOMAIN: CleanSubDomain for outbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1 Remaped Net 10000AT-REMAP: Remap for net 50 outbound subdomain 1 has been deletedAT-DOMAIN: DeleteAvRemapList for outbound subdomain 1AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]AT-DOMAIN: CleanSubDomain for inbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1AT-DOMAIN: CleanSubDomain for outbound subdomain 1AT-DOMAIN: DeleteRemapTable for subdomain 1AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1Related Command
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.
[no] debug apple routing [type number]
Syntax Description
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
Sample Display
shows sample debug apple routing output.
Figure 2-15 Sample Debug Apple Routing Output
router# debug apple routingAT: src=Ethernet0:4160.41, dst=4160-4160, size=19, 2 rtes, RTMP pkt sentAT: src=Ethernet1:41069.25, dst=41069, size=427, 96 rtes, RTMP pkt sentAT: src=Ethernet2:4161.23, dst=4161-4161, size=427, 96 rtes, RTMP pkt sentAT: 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)AT: RTMP from 4160.250 (new 0,old 0,bad 0,ign 2, dwn 0)AT: RTMP from 4161.236 (new 0,old 94,bad 0,ign 1, dwn 0)AT: src=Ethernet0:4160.41, dst=4160-4160, size=19, 2 rtes, RTMP pkt sentExplanations for representative lines of the debug apple routing output in follow.
describes the fields in the first line of sample debug apple routing output.
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)describes the fields in the following line of debug apple routing output.
AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0)
debug apple zip
Use the debug apple zip EXEC command to display debugging output from the Zone Information Protocol (ZIP) routines. The no form of this command disables debugging output.
[no] debug apple zip [type number]
Syntax Description
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 the 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
shows sample debug apple zip output.
Figure 2-16 Sample Debug Apple ZIP Output
router# debug apple zipAT: Sent GetNetInfo request broadcast on Ether0AT: Recvd ZIP cmd 6 from 4160.19-6AT: 3 query packets sent to neighbor 4160.19AT: 1 zones for 31902, ZIP XReply, src 4160.19AT: net 31902, zonelen 10, name US-FloridaExplanations of the lines of output shown in follow.
The first line indicates that the router has received an RTMP update that includes a new network number and is now requesting zone information:
AT: Sent GetNetInfo request broadcast on Ether0The 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-6The 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.19The 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.19The 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-Floridadebug appn all
Use the debug appn all EXEC command to turn on all possible debugging messages for Advanced Peer-to-Peer Networking (APPN). The no form of this command disables debugging output.
[no] debug appn all
Note
Usage Guidelines
This command shows all APPN events. Use other forms of the debug appn command to display specific types of events.
Note
CautionDebugging 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 ds
debug appn ms
debug appn nof
debug appn pc
debug appn ps
debug appn scm
debug appn ss
debug appn trsdebug appn cs
Use the debug appn cs EXEC command to display APPN Configuration Services (CS) component activity. The no form of this command disables debugging output.
[no] debug appn cs
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
shows sample debug appn cs output. In this example a link station is being stopped.
Figure 2-17 Sample Debug APPN CS Output
router# debug appn csTurned on event 008000FFrouter# appn stop link PATTYAPPN: ----- CS ----- Deq STOP_LS messageAPPN: ----- CS ----- FSM LS: 75 17 5 8APPN: ----- CS ----- Sending DEACTIVATE_AS - station PATTYAPPN: ----- CS ----- deactivate_as_p->ips_header.lpid = A80A60APPN: ----- CS ----- deactivate_as_p->ips_header.lpid = A80A60APPN: ----- CS ----- Sending DESTROY_TG to PC - station PATTY - lpid=A80A60APPN: ----- CS ----- Deq DESTROY_TG - station PATTYAPPN: ----- CS ----- FSM LS: 22 27 8 0APPN: ----- CS ----- Sending TG update for LS PATTY to TRSAPPN: ----- CS ----- ENTERING XID_PROCESSING: 4%APPN-6-APPNSENDMSG: Link Station PATTY stoppedshows describes the fields and messages shown in .
Related Command
debug appn ds
Use the debug appn ds EXEC command to display debugging information on APPN Directory Services (DS) component activity. The no form of this command disables debugging output.
[no] debug appn ds
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
shows sample debug appn ds output. In this example a search has been received.
Figure 2-18 Sample Debug APPN DS Output
router# debug appn dsTurned on event 080000FFAPPN: NEWDS: LS: search from: NETA.PATTYAPPN: NEWDS: pcid: DD3321E8B5667111APPN: NEWDS: Invoking FSM NNSoluAPPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 0 col: 0 inp: 80200000APPN: NEWDS: LSfsm_parent: 00A89940 row: 0 col: 0 inp: 80000000APPN: NEWDS: Rcvd a LMRQAPPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 12 col: 1 inp: 40000000APPN: NEWDS: LSfsm_parent: 00A89940 row: 8 col: 1 inp: 40000000APPN: NEWDS: LSfsm_child: 00A89BE8 row: 0 col: 0 inp: 80000080APPN: NEWDS: PQenq REQUEST_ROUTE(RQ) to TRSAPPN: NEWDS: LSfsm_child: 00A8A1C0 row: 1 col: 0 inp: 80000008APPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 5 col: 1 inp: 80C04000APPN: NEWDS: LSfsm_child: 00A8A1C0 row: 7 col: 1 inp: 80844008APPN: NEWDS: Rcvd a LMRYAPPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 16 col: 6 inp: 40800000APPN: NEWDS: LSfsm_child: 00A8A1C0 row: 14 col: 5 inp: 40800000APPN: NEWDS: LSfsm_parent: 00A89940 row: 3 col: 1 inp: 80840000APPN: NEWDS: send locate to node: NETA.PATTYprovides explanations for fields in the debug appn ds output shown in .
Related Command
debug appn ms
Use the debug appn ms EXEC command to display debugging information on APPN Management Services (MS) component activity. The no form of this command disables debugging output.
[no] debug appn ms
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
shows sample debug appn ms output. In this example an error occurred that caused an alert to be generated.
Figure 2-19 Sample Debug APPN MS Output
router# debug appn msAPPN: ----- MSS00 ---- Deq ALERT_MSU msgAPPN: --- MSP70 --- ALERT MV FROM APPN WITH VALID LGTHAPPN: --- MSCPL --- Find Active FPAPPN: --- MSP30 --- Entering Build MS TransportAPPN: --- MSP31 --- Entering Building Routing Info.APPN: --- MSP34 --- Entering Build GDSAPPN: --- MSP32 --- Entering Building UOW correlatorAPPN: --- MSP34 --- Entering Build GDSAPPN: --- MSP30 --- Building GDS 0x1310APPN: --- MSP30 --- Building MS TransportAPPN: --- MSP72 --- ACTIVE FP NOT FOUND, SAVE ONLYAPPN: --- MSUTL --- UOW <= 60, ALL COPIED in extract_uowAPPN: --- MSCAT --- by enq_cached_ms QUEUE SIZE OF QUEUE after enq 4describes fields in the debug appn ms output shown in .
Table 2-11 Debug APPN MS Output Field Descriptions
APPN
Indicates that this is APPN debugging output.
MSP
Indicates that this is MS component output.
Related Command
debug appn nof
Use the debug appn nof EXEC command to display debugging information on APPN Node Operator Facility (NOF) component activity. The no form of this command disables debugging output.
[no] debug appn nof
Usage Guidelines
The Node Operator Facility (NOF) component is responsible for processing commands entered by the user such as start, stop, show, and configuration commands. NOF forwards these commands to the proper component and wait for the response.
Sample Display
shows sample debug appn nof output. In this example an APPN connection network is being defined.
Figure 2-20 Sample Debug APPN NOF Output
router# debug appn nofTurned on event 010000FFrouter# config termEnter configuration commands, one per line. End with CNTL/Z.router(config)#appn connection-network NETA.CISCOrouter(config-appn-cn)#port TR0router(config-appn-cn)#completerouter(config)#APPN: ----- NOF ----- Define Connection Network Verb ReceivedAPPN: ----- NOF ----- send define_cn_t ips to csAPPN: ----- NOF ----- waiting for define_cn rsp from csrouter(config)#describes fields in the debug appn nof output shown in .
Related Command
debug appn pc
Use the debug appn pc EXEC command to display debugging information on APPN Path Control (PC) component activity. The no form of this command disables debugging output.
[no] debug appn pc
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
shows sample debug appn pc output. In this example a MU is received from the network.
Figure 2-21 Sample Debug APPN PC Output
router# debug appn pcTurned on event 040000FFAPPN: ----- PC-----PC Deq REMOTE msg variant_name 2251APPN: --PC-- mu received to PC lpid: A80AECAPPN: --PC-- mu received from p_cep_id: 67C6F8APPN: ----- PC-----PC Deq LSA_IPS from DLCAPPN: --PCX dequeued a DATA.INDAPPN: --- PC processing DL_DATA.indAPPN: --PC-- mu_error_checker with no error, calling frrAPPN: --PC-- calling frr for packet received on LFSID: 1 2 3APPN: ----- PC-----PC is sending MU to SC A90396APPN: ----- SC-----send mu: A90396, rpc: 0, nws: 7, rh.b1: 90APPN: SC: Send mu.snf: 8, th.b0: 2E, rh.b1: 90, dcf: 8describes fields in the debug appn pc output shown in .
Related Command
debug appn ps
Use the debug appn ps EXEC command to display debugging information on APPN Presentation Services (PS) component activity. The no form of this command disables debugging output.
[no] debug appn ps
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
shows sample debug appn ps output. In this example a CP capabilities exchange is in progress.
Figure 2-22 Sample Debug APPN PS Output
router# debug appn psTurned on event 200000FFAPPN: ---- CCA --- CP_CAPABILITIES_TP has startedAPPN: ---- CCA --- About to wait for Partner to send CP_CAPAPPN: ---- CCA --- Partner LU name: NETA.PATTYAPPN: ---- CCA --- Mode Name: CPSVCMGAPPN: ---- CCA --- CGID: 78APPN: ---- CCA --- About to send cp_cp_session_act to SSAPPN: ---- CCA --- Waiting for cp_cp_session_act_rsp from SSAPPN: ---- CCA --- Received cp_cp_session_act_rsp from SSAPPN: ---- CCA --- About to send CP_CAP to partnerAPPN: ---- CCA --- Send to partner completed with rc=0, 0APPN: ---- RCA --- Allocating conversationAPPN: ---- RCA --- Sending CP_CAPABILITIESAPPN: ---- RCA --- Getting conversation attributesAPPN: ---- RCA --- Waiting for partner to send CP_CAPABILITIESAPPN: ---- RCA --- Normal processing complete with cgid = 82APPN: ---- RCA --- Deallocating CP_Capabilities conversationdescribes fields in the debug appn ps output shown in .
Table 2-14 Debug APPN PS Field Descriptions
APPN
APPN debugging output.
CCA
CP Capabilities TP output.
RCA
Receive CP Capabilities TP output.
Related Command
debug appn scm
Use the debug appn scm EXEC command to display debugging information on APPN Session Connector Manager (SCM) component activity. The no form of this command disables debugging output.
[no] debug appn scm
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
shows sample debug appn scm output. In this example an intermediate session traffic is being routed.
Figure 2-23 Sample Debug APPN SCM Output
router# debug appn scmTurned on event 020000FFrouter#APPN: ----- SCM-----SCM Deq a MUAPPN: ----- SCM-----SCM send ISR_INIT to SSIAPPN: ----- SCM-----(i05) Enter compare_fqpcid()APPN: ----- SCM-----Adding new session_info table entry. addr=A93160APPN: ----- SCM-----SCM Deq ISR_CINIT messageAPPN: ----- SCM-----(i05) Enter compare_fqpcid()APPN: ----- SCM-----SCM sends ASSIGN_LFSID to ASMAPPN: ----- SCM-----SCM Rcvd sync ASSIGN_LFSID from ASMAPPN: ----- SCM-----SCM PQenq a MU to ASMAPPN: ----- SCM-----SCM Deq a MUAPPN: ----- SCM-----(i05) Enter compare_fqpcid()APPN: ----- SCM-----SCM PQenq BIND rsp to ASMdescribes fields in the debug appn ps output shown in .
Table 2-15 Debug APPN SCM Field Descriptions
APPN
APPN debugging output.
SCM
SCM component output.
Related Command
debug appn ss
Use the debug appn ss EXEC command to display session services (SS) events. The no form of this command disables debugging output.
[no] debug appn ss
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
shows sample debug appn ss output. In this example CP-CP sessions between the router and another node are being activated.
Figure 2-24 Sample Debug APPN SS Output
router# debug appn ssTurned on event 100000FFAPPN: ----- SS ----- Deq ADJACENT_CP_CONTACTED messageAPPN: ----- SS ----- Deq SESSST_SIGNAL messageAPPN: ----- SS ----- Deq CP_CP_SESSION_ACT messageAPPN: Sending ADJACENT_NN_1015 to SCM, adj_node_p=A6B980,cp_name=NETA.PATTYAPPN: ----- SS ----- Sending REQUEST_LAST_FRSN message to TRSAPPN: ----- SS ----- Receiving REQUEST_LAST_FRSN_RSP from TRSAPPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to DSAPPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to MSAPPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to TRSAPPN: ----- SS ----- Sending CP_CP_SESSION_ACT_RSP message to CCA TPAPPN: ----- SS ----- Sending PENDING_ACTIVE CP_STATUS CONWINNER message to DSAPPN: ----- SS ----- Sending REQUEST_LAST_FRSN message to TRSAPPN: ----- SS ----- Receiving REQUEST_LAST_FRSN_RSP from TRSAPPN: ----- SS ----- Sending ACT_CP_CP_SESSION message to RCA TPAPPN: ----- SS ----- Deq ASSIGN_PCID messageAPPN: ----- SS ----- Sending ASSIGN_PCID_RSP message to someoneAPPN: ----- SS ----- Deq INIT_SIGNAL messageAPPN: ----- SS ----- Sending REQUEST_COS_TPF_VECTOR message to TRSAPPN: ----- SS ----- Receiving an REQUEST_COS_TPF_VECTOR_RSP from TRSAPPN: ----- SS ----- Sending REQUEST_SINGLE_HOP_ROUTE message to TRSAPPN: ----- SS ----- Receiving an REQUEST_SINGLE_HOP_ROUTE_RSP from TRSAPPN: ----- SS ----- Sending ACTIVATE_ROUTE message to CSAPPN: ----- SS ----- Deq ACTIVATE_ROUTE_RSP messageAPPN: ----- SS ----- Sending CINIT_SIGNAL message to SMAPPN: ----- SS ----- Deq ACT_CP_CP_SESSION_RSP messageAPPN: -- SS----SS ssp00, act_cp_cp_session_rsp received, sense_code=0, cgid=5C, ips@=A93790APPN: Sending ADJACENT_NN_1015 to SCM, adj_node_p=A6B980,cp_name=18sAPPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to DSAPPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to MSAPPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to TRSdescribes fields in the debug appn ss output shown in .
Table 2-16 Debug APPN SS Field Descriptions
APPN
APPN debugging output.
SS
SS component output.
Related Command
debug appn trs
Use the debug appn trs EXEC command to display debugging information on APPN Topology and Routing Services (TRS) component activity. The no form of this command disables debugging output.
[no] debug appn trs
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
shows sample debug appn trs output.
Figure 2-25 Sample Debug APPN TRS Output
router# debug appn trsTurned on event 400000FFAPPN: ----- TRS ----- Received a QUERY_CPNAMEAPPN: ----- TRS ----- Received a REQUEST_ROUTEAPPN: ----- TRS ----- check_node node_name=NETA.LISAAPPN: ----- TRS ----- check_node node_index=0APPN: ----- TRS ----- check_node node_weight=60APPN: ----- TRS ----- add index 484 to origin description listAPPN: ----- TRS ----- add index 0 to dest description listAPPN: ----- TRS ----- origin tg_vector is NULLAPPN: ----- TRS ----- weight_to_origin = 0APPN: ----- TRS ----- weight_to_dest = 0APPN: ----- TRS ----- u_b_s_f weight = 30APPN: ----- TRS ----- u_b_s_f prev_weight = 2147483647APPN: ----- TRS ----- u_b_s_f origin_index = 484APPN: ----- TRS ----- u_b_s_f dest_index = 0APPN: ----- TRS ----- b_r_s_f weight = 30APPN: ----- TRS ----- b_r_s_f origin_index = 484APPN: ----- TRS ----- b_r_s_f dest_index = 0APPN: ----- TRS ----- Received a REQUEST_ROUTEAPPN: ----- TRS ----- check_node node_name=NETA.LISAAPPN: ----- TRS ----- check_node node_index=0APPN: ----- TRS ----- check_node node_weight=60APPN: ----- TRS ----- check_node node_name=NETA.BARTAPPN: ----- TRS ----- check_node node_index=484APPN: ----- TRS ----- check_node node_weight=60APPN: ----- TRS ----- add index 484 to origin description listAPPN: ----- TRS ----- add index 0 to dest description listAPPN: ----- TRS ----- origin_tg_weight to non-VN=30APPN: ----- TRS ----- origin_node_weight to non-VN=60APPN: ----- TRS ----- weight_to_origin = 90APPN: ----- TRS ----- weight_to_dest = 0APPN: ----- TRS ----- u_b_s_f weight = 120APPN: ----- TRS ----- u_b_s_f prev_weight = 2147483647APPN: ----- TRS ----- u_b_s_f origin_index = 484APPN: ----- TRS ----- u_b_s_f dest_index = 0APPN: ----- TRS ----- b_r_s_f weight = 120APPN: ----- TRS ----- b_r_s_f origin_index = 484APPN: ----- TRS ----- b_r_s_f dest_index = 0describes fields in the debug appn trs output shown in .
Table 2-17 Debug APPN TRS Field Descriptions
APPN
APPN debugging output.
TRS
TRS component output.
Related Command
debug arap
Use the debug arap EXEC command to display AppleTalk Remote Access Protocol (ARAP) events. The no form of this command disables debugging output.
debug arap [internal]
no debug arapSyntax Description
Usage Guidelines
Use the debug arap command with the debug callback command on access servers to debug dial-in and callback events.
Sample Display
shows sample debug arap output.
Figure 2-26 Sample Debug ARAP Output
router# debug arap internalARAP: ---------- SRVRVERSION ----------ARAP: ---------- ACKing 0 ----------ARAP: ---------- AUTH_CHALLENGE ----------arapsec_local_account setting up callbackARAP: ---------- ACKing 1 ----------ARAP: ---------- AUTH_RESPONSE ----------arap_startup initiating callback ARAP 2.0ARAP: ---------- CALLBACK ----------TTY7 Callback process initiated, user: dialback dialstring 40TTY7 Callback forced wait = 4 secondsTTY7 ARAP Callback Successful - await exec/autoselect pickupTTY7: Callback in effectARAP: ---------- STARTINFOFROMSERVER ----------ARAP: ---------- ACKing 0 ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------The displayed information is self-explanatory.
Related Command
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.
[no] debug arp
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
shows sample debug arp output.
Figure 2-27 Sample Debug ARP Output
router# debug arpIP ARP: sent req src 172.16.22.7 0000.0c01.e117, dst 172.16.22.96 0000.0000.0000IP ARP: rcvd rep src 172.16.22.96 0800.2010.b908, dst 172.16.22.7IP ARP: rcvd req src 172.16.6.10 0000.0c00.6fa2, dst 172.16.6.62IP ARP: rep filtered src 172.16.22.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffffIP ARP: rep filtered src 172.16.9.7 0000.0c00.6b31, dst 172.16.22.7 0800.2010.b908In , 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 172.16.22.7 and MAC address 0000.0c01.e117 sent an ARP request for the MAC address of the host at 172.16.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 172.16.22.7 0000.0c01.e117, dst 172.16.22.96 \0000.0000.0000The second line indicates that the router at IP address 172.16.22.7 receives a reply from the host at 172.16.22.96 indicating that its MAC address is 0800.2010.b908:
IP ARP: rcvd rep src 172.16.22.96 0800.2010.b908, dst 172.16.22.7The third line indicates that the router receives an ARP request from the host at 172.16.6.10 requesting the MAC address for the host at 172.16.6.62:
IP ARP: rcvd req src 172.16.6.10 0000.0c00.6fa2, dst 172.16.6.62The 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 172.16.22.7 aa92.1b36.a456, dst 255.255.255.255 \ffff.ffff.ffffThe fifth line indicates that another host on the network attempted to inform the router that it is on network 172.16.9.7, but the router does not know that the 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 172.16.9.7 0000.0c00.6b31, dst 172.16.22.7 \0800.2010.b908debug atm errors
Use the debug atm errors EXEC command to display Asynchronous Transfer Mode (ATM) errors. The no form of this command disables debugging output.
[no] debug atm errors
Sample Display
shows sample debug atm errors output.
Figure 2-28 Sample Debug ATM Errors Output
router# debug atm errorsATM(ATM2/0): Encapsulation error, link=7, host=836CA86D.ATM(ATM4/0): VCD#7 failed to echo OAM. 4 triesThe first line of output in 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 atm events
Use the debug atm events EXEC command to display ATM events. The no form of this command disables debugging output.
[no] debug atm events
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
shows sample debug atm events output.
Figure 2-29 Sample Debug ATM Events Output
router# debug atm eventsATM events debugging is onRESET(ATM4/0): PLIM type is 1, Rate is 100Mbpsaip_disable(ATM4/0): state=1config(ATM4/0)aip_love_note(ATM4/0): asr=0x201aip_enable(ATM4/0)aip_love_note(ATM4/0): asr=0x4000aip_enable(ATM4/0): restarting VCs: 7aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:2 vpi:2 vci:2aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:3 vpi:3 vci:3aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:4 vpi:4 vci:4aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:6 vpi:6 vci:6aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:7 vpi:7 vci:7aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:11 vpi:11 vci:11aip_love_note(ATM4/0): asr=0x200describes significant fields in the output shown in .
Explanations for representative lines of output in follow.
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 100MbpsThe 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=1The following line indicates that a configuration command has been completed by the AIP:
aip_love_note(ATM4/0): asr=0x201The 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:
aip_love_note(ATM4/0): asr=0x4000The following line of output indicates that the AIP enable function is restarting all PVCs automatically:
aip_enable(ATM4/0): restarting VCs: 7The following lines of output indicate that PVC 1 was set up and a successful completion code was returned:
aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1aip_love_note(ATM4/0): asr=0x200debug atm oam
Use the debug atm oam EXEC command to display ATM operation and maintenance (OAM) events. The no form of this command disables debugging output.
[no] debug atm oam
Sample Display
shows sample debug atm oam output.
Figure 2-30 Sample Debug ATM OAM Output
router# debug atm oamATM4/0(O): VCD:0x0 DM:0x300 *OAM Cell* Length:0x390000 0300 0070 007A 0018 0100 0000 05FF FFFF FFFF FFFF FFFF FFFF FFFF FFFFFFFF FFFF FFFF FFFF FF6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A00 0000describes the output fields shown in .
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 command disables debugging output.
[no] debug atm packet [interface atm number [vcd vcd-number]]
Syntax Description
interface number
(Optional) ATM interface or subinterface number.
vcd vcd-number
(Optional) Number of the virtual circuit designator (VCD).
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
Sample Display
shows sample debug atm packet output.
Figure 2-31 Sample Debug ATM Packet Output
router# debug atm packetATM packets debugging is onrouter#ATM2/0(O): VCD: 0x1,DM: 1C00, MUX, ETYPE: 0800,Length: 324500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105describes significant fields shown in .
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 0000A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105debug 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.
[no] debug bri
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
Sample Display
shows sample debug bri output.
Figure 2-32 Sample Debug BRI Packets Output
Router# debug briBasic Rate network interface debugging is onBRI: write_sid: wrote 1B for subunit 0, slot 1.BRI: write_sid: wrote 15 for subunit 0, slot 1.BRI: write_sid: wrote 17 for subunit 0, slot 1.BRI: write_sid: wrote 6 for subunit 0, slot 1.BRI: write_sid: wrote 8 for subunit 0, slot 1.BRI: write_sid: wrote 11 for subunit 0, slot 1.BRI: write_sid: wrote 13 for subunit 0, slot 1.BRI: write_sid: wrote 29 for subunit 0, slot 1.BRI: write_sid: wrote 1B for subunit 0, slot 1.BRI: write_sid: wrote 15 for subunit 0, slot 1.BRI: write_sid: wrote 17 for subunit 0, slot 1.BRI: write_sid: wrote 20 for subunit 0, slot 1.BRI: Starting Power Up timer for unit = 0.BRI: write_sid: wrote 3 for subunit 0, slot 1.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 B1BRI: write_sid: wrote 14 for subunit 0, slot 1.%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 B1BRI: write_sid: wrote 15 for subunit 0, slot 1.%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 downExplanations for individual lines of output from follow.
The following line indicates that an internal command was written to the interface controller. The subunit identifies the first interface in the slot:
BRI: write_sid: wrote 1B for subunit 0, slot 1.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 downThe following line indicates that the channel was disabled:
BRI: disable channel B1Lines of output not described are for use by support staff only.
Related Commands
debug isdn event
debug isdn q921
debug isdn q931debug bsc event
Use the debug bsc event EXEC command to display all events occurring in the Binary Synchronous Communications (BSC) feature. The no form of this command disables debugging output.
[no] debug bsc event [ number]
Syntax Description
Usage Guidelines
This command traces all interfaces configured with a bsc protocol-group number command.
Sample Display
shows sample debug bsc event output.
Figure 2-33 Sample Debug BSC Event Output
router# debug bsc eventBSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFileBSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFileBSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFile0:04:32: BSC: Serial2 :SDI-rx: 9 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Down new_st:TCU_EOFile0:04:32: BSC: Serial2 :SDI-rx: 5 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Down new_st:TCU_EOFileBSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Down new_st:TCU_InFileBSC: 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 upBSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Idle new_st:TCU_InFile0:04:35: BSC: Serial2 :SDI-rx: 9 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Idle new_st:TCU_InFile0:04:35: BSC: Serial2 :SDI-rx: 5 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Idle new_st:TCU_InFile0:04:35: BSC: Serial2 :NDI-rx: 3 bytesRelated Commands
debug bsc packet
debug bstun eventsdebug bsc packet
Use the debug bsc packet EXEC command to display all frames traveling through the Binary Synchronous Communications (BSC) feature. The no form of this command disables debugging output.
[no] debug bsc packet [group number] [buffer-size bytes]
Syntax Description
group number
(Optional) Group number.
buffer-size bytes
(Optional) Number of bytes displayed per packet (defaults to 20).
Usage Guidelines
This command traces all interfaces configured with a bsc protocol-group number command.
Sample Display
shows sample debug bsc packet output.
Figure 2-34 Sample Debug BSC Packet Output
router# debug bsc packet0:23:33: BSC: Serial2 :NDI-rx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D40130:23:33: BSC: Serial2 :SDI-tx : 12 bytes 00323237FF3232606040402D0:23:33: BSC: Serial2 :SDI-rx : 2 bytes 10700:23:33: BSC: Serial2 :SDI-tx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D40130:23:33: BSC: Serial2 :SDI-rx : 2 bytes 10610:23:33: BSC: Serial2 :SDI-tx : 5 bytes 00323237FFRelated Commands
debug bsc event
debug bstun eventsdebug bstun events
Use the debug bstun events EXEC command to display BSTUN connection events and status. The no form of this command disables debugging output.
[no] debug bstun events [number]
Syntax Description
Usage Guidelines
When you enable the debug bstun events command, messages showing connection establishment and other overall status messages are displayed.
You can use the debug bstun events command to assist you in determining whether the BSTUN peers are configured correctly and are communicating. For example, if you enable the debug bstun packet command and you do not see any packets, you may want to enable event debugging.
Note
Sample Displays
shows a sample debug bstun events output of keepalive messages working correctly. If the routers are configured correctly, at least one router will show reply messages.
Figure 2-35 Sample Debug BSTUN Events Output—Keepalive Messages
BSTUN: Received Version Reply opcode from (all[2])_172.16.12.2/1976 at 1360BSTUN: Received Version Request opcode from (all[2])_172.16.12.2/1976 at 1379BSTUN: Received Version Reply opcode from (all[2])_172.16.12.2/1976 at 1390
Note
shows a sample debug bstun events output of an event trace in which the wrong TCP address has been specified for the remote peer. These are non-keepalive related messages.
Figure 2-36 Sample Debug BSTUN Events Output—Event Trace
BSTUN: Change state for peer (C1[1])172.16.12.22/1976 (closed->opening)BSTUN: Change state for peer (C1[1])172.16.12.22/1976 (opening->open wait)%BSTUN-6-OPENING: CONN: opening peer (C1[1])172.16.12.22/1976, 3BSTUN: tcpd sender in wrong state, dropping packetBSTUN: tcpd sender in wrong state, dropping packetBSTUN: tcpd sender in wrong state, dropping packetRelated Commands
debug bsc event
debug bsc packet
debug bstun packetdebug bstun packet
Use the debug bstun packet EXEC command to display packet information on packets traveling through the BSTUN links. The no form of this command disables debugging output.
[no] debug bstun packet [group number] [buffer-size bytes]
Syntax Description
group number
(Optional) BSTUN group number.
buffer-size bytes
(Optional) Number of bytes displayed per packet (defaults to 20).
Sample Display
shows sample debug bstun packet output.
Figure 2-37 Sample Debug BSTUN Packet Output
router# debug bstun packetBSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1BSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1BSTUN bsc-local-ack: 0:00:06 Serial2 NDI: Addr: 40 Data: 0227F5C31140C11D60C8Related Command
debug callback
Use the debug callback EXEC 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.
[no] debug callback
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
shows sample debug callback output.
Figure 2-38 Sample Debug Callback Output
router# debug callbackTTY7 Callback process initiated, user: exec_test dialstring 123456TTY7 Callback forced wait = 4 secondsTTY7 Exec Callback Successful - await exec/autoselect pickupTTY7: Callback in effectRelated Commands
debug cdp
Use the debug cdp EXEC command to enable debugging of Cisco Discovery Protocol (CDP). The no form of this command disables debugging output.
[no] debug cdp {packets | adjacency | events}
Syntax Description
packets
Enables packet-related debugging output.
adjacency
Enables adjacency-related debugging output.
events
Enables output related to error messages, such as detecting a bad checksum.
Usage Guidelines
Use debug cdp commands to display information about CDP packet activity, activity between CDP neighbors, and various CDP events.
Sample Display
shows a composite sample output from debug cdp packets, debug cdp adjacency, and debug cdp events.
Figure 2-39 Sample Debug CDP Output
router# debug cdp packetsCDP packet info debugging is onrouter# debug cdp adjacencyCDP neighbor info debugging is onrouter# debug cdp eventsCDP events debugging is onCDP-PA: Packet sent out on Ethernet0CDP-PA: Packet received from gray.cisco.com on interface Ethernet0CDP-AD: Deleted table entry for violet.cisco.com, interface Ethernet0CDP-AD: Interface Ethernet2 coming upCDP-EV: Encapsulation on interface Serial2 failedThe messages displayed by debug cdp commands are self-explanatory.
debug cdp ip
Use the debug cdp ip EXEC command to enable debug output for the IP routing information that is carried and processed by the Cisco Discovery Protocol (CDP). The no form of this command disables debugging output.
[no] debug cdp ip
Usage Guidelines
CDP is a media- and protocol-independent device-discovery protocol that runs on all Cisco routers.
You can use the debug cdp ip command to determine the IP network prefixes CDP is advertising and whether CDP is correctly receiving this information from neighboring routers.
Use the debug cdp ip command with the debug ip routing command to debug problems that occur when on-demand routing (ODR) routes are not installed in the routing table at a hub router. You can also use the debug cdp ip command with the debug cdp packet and debug cdp adjacency commands along with encapsulation-specific debug commands to debug problems that occur in the receipt of CDP IP information.
Sample Display
shows sample debug cdp ip output. This example shows the transmission of IP-specific information in a CDP update. In this case, three network prefixes are being transmitted, each with a different network mask.
Figure 2-40 Sample Debug CDP IP Output
router# debug cdp ipCDP-IP: Writing prefix 172.1.69.232.112/28CDP-IP: Writing prefix 172.19.89.0/24CDP-IP: Writing prefix 11.0.0.0/8In addition to the messages shown in , you might see the following messages:
•
CDP-IP: Updating prefix 172.1.1.0/24 in routing table•
CDP-IP: IP TLV length (3) invalid•
CDP-IP: Reading prefix 172.1.1.0/24 source 10.0.0.1 via Ethernet0/0Related Commands
debug cdp adjacency
debug cdp packet
debug ip routingdebug channel events
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
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
shows sample debug channel events output.
Figure 2-41 Sample Debug Channel Events Output
Router# debug channel eventsChannel3/0: cip_reset(), state administratively downChannel3/0: cip_reset(), state upChannel3/0: sending nodeidChannel3/0: sending command for vc 0, CLAW path C700, device C0Explanations for individual lines of output from follow.
The following line indicates that the CIP is being reset to an administrative down state:
Channel3/0: cip_reset(), state administratively downThe following line indicates that the CIP is being reset to an administrative up state:
Channel3/0: cip_reset(), state upThe 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 nodeidThe 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 virtual circuit number 0 with this device. The virtual 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 C0Related Commands
debug channel love
debug channel packetsdebug channel love
Use the debug channel love EXEC 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 disables debugging output.
[no] debug channel love
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
shows sample debug channel love output.
Figure 2-42 Sample Debug Channel Love Output
Router# debug channel loveChannel3/1: love letter received, bytes 3308Channel3/0: love letter received, bytes 3336cip_love_letter: received ll, but no cip_infoThe following line indicates that data was received on the CIP:
Channel3/1: love letter received, bytes 3308The 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_infoRelated Commands
debug channel events
debug channel packetsdebug channel packets
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 command disables debugging output.
[no] debug channel packets
Usage Guidelines
The debug channel packets command displays all process-level Channel Interface Processor (CIP) packets for both outbound 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
shows sample debug channel packets output.
Figure 2-43 Sample Debug Channel Packets Output
Router# debug channel packetsChannel packets debugging is on(Channel3/0)-out size = 104, vc = 0000, type = 0800, src 172.24.0.11, dst 172.24.1.58(Channel3/0)-in size = 48, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197(Channel3/0)-in size = 48, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197(Channel3/0)-out size = 71, vc = 0000, type = 0800, src 172.24.15.197, dst 172.24.1.58(Channel3/0)-in size = 44, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197provides explanations for individual lines of output from .
Related Commands
debug channel events
debug channel lovedebug 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
Sample Display
shows sample debug clns esis events output.
Figure 2-44 Sample Debug CLNS ESIS Events Output
router# debug clns esis eventsES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20Explanations for individual lines of output from follow.
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 30The 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 150The 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 20debug 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
Sample Display
shows sample debug clns esis packets output.
Figure 2-45 Sample Debug CLNS ESIS Packets Output
router# debug clns esis packetsES-IS: ISH sent to All ESs (Ethernet0): NET47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33ES-IS: ISH sent to All ESs (Ethernet1): NET47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299ES-IS: ISH sent to All ESs (Tunnel0): NET47.0005.80ff.ef00.0000.0001.5940.1600.O906.4023.00, HT 299, HLEN 34IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300Explanations for individual lines of output from follow.
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.
ES-IS: ISH sent to All ESs (Ethernet0): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33The 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. The hold time for this packet is 299 seconds. The packet header is 33 bytes in length.
ES-IS: ISH sent to All ESs (Ethernet1): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34The 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 299The 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 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.
ES-IS: ISH sent to All ESs (Tunnel0): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34The 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 300debug clns events
Use the debug clns events EXEC command to display CLNS events that are occurring at the router. The no form of this command disables debugging output.
[no] debug clns events
Sample Display
shows sample debug clns events output.
Figure 2-46 Sample Debug CLNS Events Output
router# debug clns eventsCLNS: 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.00via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)CLNS: Forwarding packet size 117from 39.0001.2222.2222.2222.00to 49.0002.0001.AAAA.AAAA.AAAA.00via 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.b5a3Explanations for individual lines of output from follow.
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.00via 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.
CLNS: Forwarding packet size 117from 39.0001.2222.2222.2222.00to 49.0002.0001.AAAA.AAAA.AAAA.00via 49.0002 (Ethernet3 0000.0c00.b5a3)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.b5a3debug 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
Sample Display
shows sample debug clns igrp packets output.
Figure 2-47 Sample Debug CLNS IGRP Packets Output
router# debug clns igrp packetsISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51ISO-IGRP: Originating level 1 periodic updateISO-IGRP: Advertise dest: 2222.2222.2222ISO-IGRP: Sending update on interface: Ethernet3ISO-IGRP: Originating level 2 periodic updateISO-IGRP: Advertise dest: 0001ISO-IGRP: Sending update on interface: Ethernet3ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)ISO-IGRP: Opcode: areaISO-IGRP: Received level 2 adv for 0001 metric 1100ISO-IGRP: Opcode: stationISO-IGRP: Received level 1 adv for 3333.3333.3333 metric 1100Explanations for individual lines of output from follow.
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_green1The 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 51The 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: Originating level 1 periodic updateISO-IGRP: Advertise dest: 2222.2222.2222ISO-IGRP: Sending update on interface: Ethernet3The 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: Originating level 2 periodic updateISO-IGRP: Advertise dest: 0001ISO-IGRP: Sending update on interface: Ethernet3The 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: areaThe 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 1100ISO-IGRP: Opcode: stationdebug 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.
[no] debug clns packet
Sample Display
shows sample debug clns packet output.
Figure 2-48 Sample Debug CLNS Packet Output
router# debug clns packetCLNS: Forwarding packet size 157from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBSto 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)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 to47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)Explanations for individual lines of output from follow.
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.
CLNS: Forwarding packet size 157from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBSto 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)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.00via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)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.
[no] debug clns routing
Sample Display
shows sample debug clns routing output.
Figure 2-49 Sample Debug CLNS Routing Output
router# debug clns routingCLNS-RT: cache increment:17CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06Explanations for individual lines of output from follow.
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:17The 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 packet's 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.3002The 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.06CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06debug cls message
Use the debug cls message EXEC command to display information about Cisco Link Services (CLS) messages. The no form of this command disables debugging output.
[no] debug cls message
Usage Guidelines
The debug cls message command displays the primitives (state), selector, header length, and data size.
Sample Display
shows sample debug cls message output. For example, CLS-->DLU indicates the direction of the flow that is described by the status. From CLS to DLU, a request was established to the connection end point. The header length is 48 bytes, and the data size is 104 bytes.
The status possibilities include the following: enabled, disabled, request open station, open station, close station, activate SA, deactivate SAP, XID, XID station, connect station, signal station, connect, disconnect, connected, data, flow, unnumbered data, modify SAP, test, activate ring, deactivate ring, test station, and unnumbered data station.
Figure 2-50 Sample Debug CLS Message Output
router# debug cls message(FRAS Daemon:CLS-->DLU):ID_STN.Ind to uSAP: 0x607044C4 sel: LLC hlen: 40, dlen: 54(FRAS Daemon:CLS-->DLU):ID_STN.Ind to uSAP: 0x6071B054 sel: LLC hlen: 40, dlen: 46(FRAS Daemon:DLU-->SAP):REQ_OPNSTN.Req to pSAP: 0x608021F4 sel: LLC hlen: 48, dlen: 104(FRAS Daemon:CLS-->DLU):REQ_OPNSTN.Cfm(NO_REMOTE_STN) to uCEP: 0x607FFE84 sel: LLC hlen: 48, dlen: 104Related Commands
debug fras error
debug fras message
debug fras statedebug cls vdlc
Use the debug cls vdlc EXEC command to display information about Cisco Link Services (CLS) Virtual Data Link Control (VDLC). The no form of this command disables debugging output.
[no] debug cls vdlc
Usage Guidelines
CautionUse the debug cls vdlc command with caution because it can generate a significant amount of output.
The debug cls message command displays primitive state transitions, selector, and source and destination media access control (MAC) and service access points (SAPs).
Also use the show cls command to display additional information on CLS VDLC.
Sample Displays
The following messages are sample debug cls vdlc output. In the following scenario, the SNA service point—also called native service point (NSP)—is setting up two connections through VDLC and data link switching (DLSw): one from NSP to VDLC and one from DLSw to VDLC. VDLC's task is to join the two.
The NSP initiates a connection from 4000.05d2.0001 as follows:
VDLC: Req Open Stn Req PSap 0x7ACE00, port 0x79DF98 4000.05d2.0001(0C)->4000.1060.1000(04)In the next message, VDLC sends a test station request to DLSw for destination address 4000.1060.1000.
VDLC: Send UFrame E3: 4000.05d2.0001(0C)->4000.1060.1000(00)In the next two messages, DLSw replies with test station response, and NSP goes to a half-open state. NSP is waiting for the DLSw connection to VDLC.
VDLC: Sap to Sap TEST_STN_RSP VSap 0x7B68C0 4000.1060.1000(00)->4000.05d2.0001(0C)VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPENING->VDLC_HALF_OPENThe NSP sends an exchange identification (XID) and changes state as follows:
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_HALF_OPEN->VDLC_XID_RSP_PENDINGVDLC: CEP to SAP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) via bridging SAP (DLSw)In the next several messages, DLSw initiates its connection, which matches the half-open connection with NSP.
VDLC: Req Open Stn Req PSap 0x7B68C0, port 0x7992A0 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: two-way connection establishedVDLC: 4000.1060.1000(04)->4000.05d2.0001(0C): VDLC_IDLE->VDLC_OPENIn the following messages, DLSw sends an XID response, and NSP's connection goes from the state XID Response Pending to Open. The XID exchange follows:
VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPENVDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDINGVDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04)VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPENVDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDINGVDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04)VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPENVDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDINGVDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04)VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPENVDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDINGVDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04)When DLSw is ready to connect, the front-end processor (FEP) sends a set asynchronous balanced mode extended (SABME) command as follows:
VDLC: CEP to CEP CONNECT_REQ 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPENIn the following messages, NSP accepts the connection and sends an unnumbered acknowledgment (UA) to the FEP:
VDLC: CEP to CEP CONNECT_RSP 4000.05d2.0001(0C)->4000.1060.1000(04)VDLC: FlowReq QUENCH OFF 4000.1060.1000(04)->4000.05d2.0001(0C)The following messages show the data flow:
VDLC: DATA 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: DATA 4000.05d2.0001(0C)->4000.1060.1000(04)...VDLC: DATA 4000.1060.1000(04)->4000.05d2.0001(0C)VDLC: DATA 4000.05d2.0001(0C)->4000.1060.1000(04)Related Commands
debug cls message
debug dlsw core messagedebug compress
Use the debug compress EXEC command to display compression information. The no form of this command disables debugging output.
[no] debug compress
Sample Display
shows sample debug compress output.
Figure 2-51 Sample Debug Compress Output
router# debug compressDECOMPRESS xmt_paks 5 rcv_sync 5COMPRESS xmt_paks 10 version 1COMPRESS xmt_paks 11 version 1DECOMPRESS xmt_paks 6 rcv_sync 6COMPRESS xmt_paks 12 version 1COMPRESS xmt_paks 13 version 1DECOMPRESS xmt_paks 7 rcv_sync 7COMPRESS xmt_paks 14 version 1COMPRESS xmt_paks 15 version 1describes significant fields shown in .
debug confmodem
Use the debug confmodem EXEC command to display information associated with the discovery and configuration of the modem attached to the router. The no form of this command disables debugging output.
[no] debug confmodem
Usage Guidelines
The debug confmodem command is used in debugging configurations that use the modem autoconfig command.
Sample Display
shows sample debug confmodem output. In the first three lines, the router is searching for a speed at which it can communicate with the modem. The remaining lines show the actual sending of the modem command.
Figure 2-52 Sample Debug Configuration Modem Output
router# debug confmodemTTY4:detection speed(115200) response ------TTY4:detection speed(57600) response ------TTY4:detection speed(38400) response ---OK---TTY4:Modem command: --AT&F&C1&D2S180=3S190=1S0=1--TTY4: Modem configuration suceeededTTY4: Done with modem configurationdebug cpp event
Use the debug cpp event EXEC command to display general Combinet Proprietary Protocol (CPP) events. The no form of this command disables debugging output.
[no] debug cpp event
Usage Guidelines
The CPP protocol allows a router to engage in negotiation over an ISDN B channel to establish connections with a Combinet bridge.
The debug cpp event command displays events such as CPP sequencing, group creation, and keepalives.
Sample Displays
One or more of the messages shown in appear when you use the debug cpp event command. Each message begins with the short name of the interface the event occurred on (for example, SERIAL0:1 or BRI0:1) and might contain one or more packet sequence numbers or remote site names.
Related Commands
debug cpp negotiation
debug cpp packetdebug cpp negotiation
Use the debug cpp negotiation EXEC command to display Combinet Proprietary Protocol (CPP) negotiation events. The no form of this command disables debugging output.
[no] debug cpp negotiation
Usage Guidelines
The CPP protocol allows a router to engage in negotiation over an ISDN B channel to establish connections with a Combinet bridge.
The debug cpp negotiation command displays events such as the type of packet and packet size being sent.
Sample Display
shows sample debug cpp negotiation output. In this example, a sample connection is shown.
Figure 2-53 Sample Debug CPP Negotiation Output
router# debug cpp negotiation%LINK-3-UPDOWN: Interface BRI0: B-Channel 2, changed state to down%LINK-3-UPDOWN: Interface BRI0, changed state to up%SYS-5-CONFIG_I: Configured from console by console%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to upBR0:1:(I) NEG packet - len 77attempting proto:2ether id:0040.f902.c7b4port 1 number:5559876port 2 number:5559876origination port:1remote name:berl9password is correctshows describes the fields and messages shown in .
Related Commands
debug cpp event
debug cpp packetdebug cpp packet
Use the debug cpp packet EXEC command to display Combinet Proprietary Protocol (CPP) packets. The no form of this command disables debugging output.
[no] debug cpp packet
Usage Guidelines
The CPP protocol allows a router to engage in negotiation over an ISDN B channel to establish connections with a Combinet bridge.
The debug cpp packet command displays the hexadecimal values of the packets.
Sample Display
shows sample debug cpp packet output. This example shows the interface name, packet type, packet size, and the hexadecimal values of the packet.
Figure 2-54 Sample Debug CPP Packet Output
router# debug cpp packetBR0:1:input packet - len 6000 00 00 00 00 00 00 40 F9 02 C7 B4 08 0.!6 00 0108 00 06 04 00 02 00 40 F9 02 C7 B4 83 6C A1 02!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 64/66/68 msBR0:1 output packet - len 11606 00 00 40 F9 02 C7 B4 00 00 0C 3E 12 3A 08 0045 00 00 64 00 01 00 00 FF 01 72 BB 83 6C A1 01Related Commands
debug cpp event
debug cpp negotiationdebug crypto key-exchange
Use the debug crypto key-exchange EXEC command to show Digital Signature Standard (DSS) public key exchange messages.The no form of this command disables debugging output.
[no] debug crypto key-exchange
Usage Guidelines
Encryption and authentication are provided by a software service on the router called a crypto engine. The crypto engine performs authentication through DSS public and private keys when a connection is set up. DSS is a means of sending a "signature" at the end of a message that positively identifies the author of the message. The signature cannot be forged or duplicated by others, so whoever received a message with a DSS signature knows exactly who sent the message.
If the process of exchanging DSS public keys with a peer router by means of the config crypto key-exchange command is not successful, try to exchange DSS public keys again after enabling the debug crypto key-exchange command to help you diagnose the problem.
Sample Displays
and show sample debug crypto key-exchange output. shows output from the initiating router in a key exchange. shows output from the passive router in a key exchange. The number of bytes received should match the number of bytes sent from the initiating side, although the number of messages can be different.
Figure 2-55 Sample Debug Crypto Key-Exchange Output—Initiating Router
router# debug crypto key-exchangeCRYPTO-KE: Sent 4 bytes.CRYPTO-KE: Sent 2 bytes.CRYPTO-KE: Sent 2 bytes.CRYPTO-KE: Sent 2 bytes.CRYPTO-KE: Sent 64 bytes.Figure 2-56 Sample Debug Crypto Key-Exchange Output—Passive Router
router# debug crypto key-exchangeCRYPTO-KE: Received 4 bytes.CRYPTO-KE: Received 2 bytes.CRYPTO-KE: Received 2 bytes.CRYPTO-KE: Received 2 bytes.CRYPTO-KE: Received 49 bytes.CRYPTO-KE: Received 15 bytes.Related Command
debug crypto sesmgmt
Use the debug crypto sesmgmt EXEC command to show connection setup messages and their flow through the router. The no form of this command disables debugging output.
[no] debug crypto sesmgmt
Usage Guidelines
Encryption and authentication are provided by a software service on the router called a crypto engine. The crypto engine performs authentication through DSS public and private keys when a connection is set up. DSS is a means of sending a "signature" at the end of a message that positively identifies the author of the message. The signature cannot be forged or duplicated by others, so whoever received a message with a DSS signature knows exactly who sent the message.
When connections are not completing, use the debug crypto sesmgmt command to follow the progress of connection messages as a first step in diagnosing the problem. You see a record of each connection message as the router discovers it, and can track its progress through the necessary signing, verifying, and encryption session setup operations. Other significant connection setup events, such as the pregeneration of Diffie-Hellman public numbers, are also shown. For information on Diffie-Hellman public numbers, refer to the Security Configuration Guide.
Also use the show crypto connections command to display additional information on connections.
Sample Displays
and show sample debug crypto sesmgmt output. shows messages from a router that initiates a successful connection. shows the messages from a router that receives a connection.
Figure 2-57 Sample Debug Crypto Sesmgmt Output—Initiating Router
router# debug crypto sesmgmtCRYPTO: Dequeued a message: Inititate_ConnectionCRYPTO: DH gen phase 1 status for conn_id 2 slot 0:OKCRYPTO: Signing done. Status:OKCRYPTO: ICMP message sent: s=172.21.114.163, d=172.21.114.162CRYPTO-SDU: send_nnc_req: NNC Echo Request sentCRYPTO: Dequeued a message: CRMCRYPTO: DH gen phase 2 status for conn_id 2 slot 0:OKCRYPTO: Verify done. Status=OKCRYPTO: Signing done. Status:OKCRYPTO: ICMP message sent: s=172.21.114.163, d=172.21.114.162CRYPTO-SDU: recv_nnc_rpy: NNC Echo Confirm sentCRYPTO: Create encryption key for conn_id 2 slot 0:OKCRYPTO: Replacing -2 in crypto maps with 2 (slot 0)Figure 2-58 Sample Debug Crypto Sesmgmt Output—Receiving Router
router# debug crypto sesmgmtCRYPTO: Dequeued a message: CIMCRYPTO: Verify done. Status=OKCRYPTO: DH gen phase 1 status for conn_id 1 slot 0:OKCRYPTO: DH gen phase 2 status for conn_id 1 slot 0:OKCRYPTO: Signing done. Status:OKCRYPTO: ICMP message sent: s=172.21.114.162, d=172.21.114.163CRYPTO-SDU: act_on_nnc_req: NNC Echo Reply sentCRYPTO: Create encryption key for conn_id 1 slot 0:OKCRYPTO: Replacing -2 in crypto maps with 1 (slot 0)CRYPTO: Dequeued a message: CCMCRYPTO: Verify done. Status=OKRelated Command
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.
[no] debug decnet adj
Sample Display
shows sample debug decnet adj output.
Figure 2-59 Sample Debug DECnet Adj Output
router# debug decnet adjDECnet adjacencies debugging is onrouter#DNET-ADJ: Level 1 hello from 1.3DNET-ADJ: sending hellosDNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498DNET-ADJ: Level 1 hello from 1.3DNET-ADJ: 1.5 adjacency initializingDNET-ADJ: sending triggered hellosDNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498DNET-ADJ: Level 1 hello from 1.3DNET-ADJ: 1.5 adjacency upDNET-ADJ: Level 1 hello from 1.5DNET-ADJ: 1.5 adjacency down, listener timeoutExplanations for representative lines of output in follow.
The following line indicates that the router is sending hellos to all routers on this segment, which in this case is Ethernet 0:
DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498The 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 initializingThe 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 hellosThe following line indicates that the adjacency with 1.5 is now up, or active:
DNET-ADJ: 1.5 adjacency upThe 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 timeoutThe 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_adjacencydebug 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 disables debugging output.
[no] debug decnet connects
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 anyYou 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.
Note
Sample Display
shows sample debug decnet connects output.
Figure 2-60 Sample Debug DECnet Connects Output
router# debug decnet connectsDNET-CON: list 300 item #2 matched src=19.403 dst=19.309 on Ethernet0: permittedsrcname="RICK" srcuic=[0,017]dstobj=42 id="USER"describes significant fields shown in .
debug decnet events
Use the debug decnet events EXEC command to display debugging information on DECnet events. The no form of this command disables debugging output.
[no] debug decnet events
Sample Display
shows sample debug decnet events output.
Figure 2-61 Sample Debug DECnet Events Output
router# debug decnet eventsDNET: Hello from area 50 rejected - exceeded `max area' parameter (45)DNET: Hello from area 50 rejected - exceeded `max area' parameter (45)Explanations for representative lines of output in follow.
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
Use the debug decnet packet EXEC command to display debugging information on DECnet packet events. The no form of this command disables debugging output.
[no] debug decnet packet
Sample Display
shows sample debug decnet packet output.
Figure 2-62 Sample Debug DECnet Packet Output
router# debug decnet packetDNET-PKT: src 1.4 dst 1.5 sending to PHASEVDNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0Explanations for individual lines of output from follow.
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 PHASEVThe 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, TokenRing0debug 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
Sample Display
shows sample debug decnet routing output.
Figure 2-63 Sample Debug DECnet Routing Output
router# debug decnet routingDNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34DNET-RT: Sending routesDNET-RT: Sending normal routing updates on Ethernet0DNET-RT: Sending level 1 routing updates on interface Ethernet0DNET-RT: Level1 routes from 1.5 on Ethernet0: entry for node 5 createdDNET-RT: route update triggered by after split route pointers in dn_rt_inputDNET-RT: Received level 1 routing from 1.5 on Ethernet 0 at 1:18:35DNET-RT: Sending L1 triggered routesDNET-RT: Sending L1 triggered routing updates on Ethernet0DNET-RT: removing route to node 5Explanations for individual lines of output from follow.
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:34The following line indicates that the router is sending its scheduled updates on interface Ethernet 0:
DNET-RT: Sending normal routing updates on Ethernet0The 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 interface's routing table.
DNET-RT: route update triggered by after split route pointers in dn_rt_inputThe following line indicates that the router sent the unscheduled update on Ethernet 0:
DNET-RT: Sending L1 triggered routesDNET-RT: Sending L1 triggered routing updates on Ethernet0The 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 5debug dialer events
Use the debug dialer events EXEC command to display debugging information about the packets received on a dialer interface. The no form of this command disables debugging output.
[no] debug dialer events
Sample Displays
When DDR is enabled on the interface, information concerning the cause of any call (called the Dialing cause) is displayed. The following line of output for an IP packet lists the name of the DDR interface and the source and destination addresses of the packet:
Dialing cause: Serial0: ip (s=172.16.1.111 d=172.16.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 Bridging and IBM Networking Command Reference publication.
Dialing cause: Serial1: Bridge (0x6005)Most messages are self-explanatory; however, messages that may need some explanation are described in .
describes the messages that the debug dialer events command can generate for a serial interface used as a V.25bis dialer for dial-on-demand routing (DDR).
Related Command
debug dialer packets
Use the debug dialer packets EXEC command to display debugging information about the packets received on a dialer interface. The no form of this command disables debugging output.
[no] debug dialer packets
Usage Guidelines
Most debug dialer packet messages are self-explanatory.
Sample Display
shows sample debug dialer packets output. The following message shows the interface type, the type of packet (protocol) being sent, the source and destination addresses, the size of the packet, and the default action for the packet (in this example, permit).
Figure 2-64 Sample Debug Dialer Packets Output
router# debug dialer packetsBRI0: ip (s=10.1.1.8, d=10.1.1.1), 100 bytes, interesting (ip PERMIT)Related Command
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.
[no] debug dlsw [core [circuit-number | flow-control | messages | state | xid] | local-circuit |
peer | reachability [[error | verbose] [sna | netbios]]]Syntax Description
Usage Guidelines
When you specify no optional keywords, the debug dlsw command enables all available DLSw debugging output.
Normally you only need to use the error or verbose option of the debug dlsw reachability command to help identify problems. The error option is recommended for use by customers and provides a subset of the messages from the normal event-level debugging. The verbose option provides a very detailed view of what is going on and is typically used only by service personnel.
To reduce the amount of debug information displayed, use the sna or netbios options with the debug dlsw reachability command if you know that you have an SNA or NetBIOS problem.
The DLSw core is the engine that is responsible for the establishment and maintenance of remote circuits. If possible, specifying the index of the specific circuit you want to debug reduces the amount of output displayed. However, if you want to watch a circuit initially come up, do not use the circuit-number option with the core keyword.
The core flow-control option provides information about congestion in the WAN or at the remote end station. In these cases, DLSw sends Receiver Not Ready (RNR) frames on its local circuits, throttling data traffic on established sessions and giving the congestion an opportunity to clear.
The core state option allows you to see when the circuit changes state. This capability is especially useful for determining why a session cannot be established or why a session is being disconnected.
The core XID option allows you to track the XID state machine. The router tracks XID commands and responses used in negotiations between end stations before establishing a session.
Sample Displays
The following sections show and explain some of the typical DLSw debug messages you might see when using the debug dlsw peer and debug dlsw reachability commands.
Sample Debug DLSW Peer Messages
The following messages occur when a CUR_ex (CANUREACH explorer) frame is received from other peers, and the peer statements or the promiscuous keyword have not been enabled so that the router is misconfigured:
22:42:44: DLSw: Not promiscuous - Rej conn from 172.20.96.1(2065)22:42:51: DLSw: Not promiscuous - Rej conn from 172.20.99.1(2065)In the following messages, the router sends out a keepalive message every 30 seconds to keep the peer connected. If three keepalive messages are missed, the peer is torn down. These messages are display only if keepalives are enabled (by default, keepalives are disabled).
22:44:03: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168243148)22:44:03: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168243176)22:44:34: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168274148)22:44:34: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168274172)The following peer debug messages indicate that the local peer is disconnecting from the specified remote peer due to missed peer keepalives:
0:03:24: DLSw: keepalive failure for peer on interface Serial00:03:24: DLSw: action_d(): for peer on interface Serial00:03:24: DLSW: DIRECT aborting connection for peer on interface Serial00:03:24: DLSw: peer on interface Serial0, old state CONNECT, new state DISCONNThe following peer debug messages result from an attempt to connect to an IP address that does not have DLSw enabled. The local router attempts to connect in 30-second intervals.
23:13:22: action_a() attempting to connect peer 172.20.100.1(2065)23:13:22: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]23:13:22: action_a() retries: 8 next conn time: 86123250423:13:52: action_a() attempting to connect peer 172.20.100.1(2065)23:13:52: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]23:13:52: action_a() retries: 9 next conn time: 861292536The following peer debug messages indicates a remote-peer statement is missing on the router at address 172.20.100.1 to which the connection attempt is sent:
23:14:52: action_a() attempting to connect peer 172.20.100.1(2065)23:14:52: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)23:14:52: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD23:14:52: DLSw: dlsw_tcpd_fini() closing connection for peer 172.20.100.123:14:52: DLSw: action_d(): for peer 172.20.100.1(2065)23:14:52: DLSw: aborting tcp connection for peer 172.20.100.1(2065)23:14:52: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state DISCONNThe following messages show a normal opening:
23:16:37: action_a() attempting to connect peer 172.20.100.1(2065)23:16:37: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)23:16:37: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD23:16:37: DLSW: passive open 172.20.100.1(17762) -> 206523:16:37: DLSw: action_c(): for peer 172.20.100.1(2065)23:16:37: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state CAP_EXG23:16:37: DLSw: peer 172.20.100.1(2065) conn_start_time set to 86139778423:16:37: DLSw: CapExId Msg sent to peer 172.20.100.1(2065)23:16:37: DLSw: Recv CapExId Msg from peer 172.20.100.1(2065)23:16:37: DLSw: Pos CapExResp sent to peer 172.20.100.1(2065)23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)23:16:37: DLSw: Recv CapExPosRsp Msg from peer 172.20.100.1(2065)23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)23:16:37: DLSw: peer 172.20.100.1(2065), old state CAP_EXG, new state CONNECT23:16:37: DLSw: dlsw_tcpd_fini() closing write pipe for peer 172.20.100.123:16:37: DLSw: action_g(): for peer 172.20.100.1(2065)23:16:37: DLSw: closing write pipe tcp connection for peer 172.20.100.1(2065)23:16:38: DLSw: peer_act_on_capabilities() for peer 172.20.100.1(2065)The following two messages show that an information frame is passing through:
DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:5 rs:4 i:34DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:4 rs:4 i:34Sample Debug DLSw Reachability Messages
The messages in this section are based on the following items:
•
•
•
•
•
describes the debug output indicating that the dlsw router received an SSP message that is flow controlled and should be counted against the sender's window.
Dec 6 11:26:49: CSM: Received SSP CUR csex flags = 80, mac 4000.90b1.26cf,The csex flags = 80 means that this is an CUR_ex (explorer).Dec 5 10:48:33: DLSw: 1620175180 decr r - s:27 so:0 r:27 ro:0Table 2-28 Debug Output Descriptions
The following message shows that DLSw is sending an I frame to a LAN:
Dec 5 10:48:33: DISP Sent : CLSI Msg : DATA.Req dlen: 1086The following message shows that DLSw received the I frame from the LAN:
Dec 5 10:48:35: DLSW Received-disp : CLSI Msg : DATA.Ind dlen: 4The following messages show that the reachability cache is cleared:
Router# clear dlsw rea23:44:11: CSM: Clearing CSM cache23:44:11: CSM: delete local mac cache for port 023:44:11: CSM: delete local name cache for port 023:44:11: CSM: delete remote mac cache for peer 023:44:11: CSM: delete remote name cash dlsw reaThe next group of messages show that the DLSw reachability cache is added, and that a name query is perform from the router Marian:
23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:11: CSM: update local cache for name MARIAN , port 5EFBB423:45:11: CSM: Received CLS_UDATA_STN from Core23:45:11: CSM: Received netbios frame type A23:45:11: CSM: Processing Name Query23:45:11: CSM: Netbios Name Query: ws_status = 623:45:11: CSM: Write to peer 0 ok.23:45:11: CSM: Freeing clsi message23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:11: CSM: update local cache for name MARIAN , port 658AB423:45:11: CSM: Received CLS_UDATA_STN from Core23:45:11: CSM: Received netbios frame type A23:45:11: CSM: Processing Name Query23:45:11: CSM: Netbios Name Query: ws_status = 523:45:11: CSM: DLXNR_PEND match found.... drop name query23:45:11: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:12: CSM: update local cache for name MARIAN , port 5EFBB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:12: CSM: update local cache for name MARIAN , port 658AB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:12: CSM: update local cache for name MARIAN , port 5EFBB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:12: CSM: update local cache for name MARIAN , port 658AB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:18: CSM: Deleting Reachability cache23:45:18: CSM: Deleting DLX NR pending record....23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:38: CSM: update local cache for name MARIAN , port 5EFBB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi message23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:38: CSM: update local cache for name MARIAN , port 658AB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi messageThe following messages show that Marian is added to the network:
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:38: CSM: update local cache for name MARIAN , port 5EFBB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi message23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:38: CSM: update local cache for name MARIAN , port 658AB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi messageIn the next group of messages, an attempt to add the router Ginger on the Ethernet is made:
0:07:44: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB40:07:44: CSM: 0004.f545.24e6 passes local mac excl. filter0:07:44: CSM: update local cache for mac 0004.f545.24e6, port 658AB40:07:44: CSM: update local cache for name GINGER , port 658AB40:07:44: CSM: Received CLS_UDATA_STN from Core0:07:44: CSM: Received netbios frame type 80:07:44: CSM: Write to peer 0 ok.In the following example, the output from the show dlsw reachability command indicates that Ginger is on the Ethernet interface and Marian is on the Token Ring interface:
G41#sh dlsw reaDLSw MAC address reachability cache listMac Addr status Loc. peer/port rif0004.f545.24e6 FOUND LOCAL P007-S000 --no rif--0800.5a30.7a9b FOUND LOCAL P000-S000 06C0.0621.7D00P007-S000 F0F8.0006.A6FC.005F.F100.0000.0000.0000DLSw NetBIOS Name reachability cache listNetBIOS Name status Loc. peer/port rifGINGER FOUND LOCAL P007-S000 --no rif--MARIAN FOUND LOCAL P000-S000 06C0.0621.7D00P007-S000 --no rif--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.
[no] debug dspu activation [name]
Syntax Description
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
shows sample debug dspu activation output. Not all intermediate numbers are shown for the "activated" and "deactivated" logical unit (LU) address ranges.
Figure 2-65 Sample Debug DSPU Activation Output
router# debug dspu activationDSPU: LS HOST3745 connectedDSPU: PU HOST3745 activatedDSPU: LU HOST3745-2 activatedDSPU: LU HOST3745-3 activated...DSPU: LU HOST3745-253 activatedDSPU: LU HOST3745-254 activatedDSPU: LU HOST3745-2 deactivatedDSPU: LU HOST3745-3 deactivated...DSPU: LU HOST3745-253 deactivatedDSPU: LU HOST3745-254 deactivatedDSPU: LS HOST3745 disconnectedDSPU: PU HOST3745 deactivateddescribes significant fields in the output shown in .
Related Commands
debug dspu packet
debug dspu state
debug dspu tracedebug 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.
[no] debug dspu packet [name]
Syntax Description
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
shows sample debug dspu packet output.
Figure 2-66 Sample Debug DSPU Packet Output
router# debug dspu packetDSPU: Rx: PU HOST3745 data length 12 data:2D0003002BE16B80 000D0201DSPU: Tx: PU HOST3745 data length 25 data:2D0000032BE1EB80 000D020100850000 000C060000010000 00DSPU: Rx: PU HOST3745 data length 12 data:2D0004002BE26B80 000D0201DSPU: Tx: PU HOST3745 data length 25 data:2D0000042BE2EB80 000D020100850000 000C060000010000 00describes significant fields in the output shown in .
Related Commands
debug dspu activation
debug dspu state
debug dspu tracedebug 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.
[no] debug dspu state [name]
Syntax Description
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
shows sample debug dspu state output. Not all intermediate numbers are shown for the "activated" and "deactivated" logical unit (LU) address ranges.
Figure 2-67 Sample Debug DSPU State Output
router# debug dspu stateDSPU: LS HOST3745: input=StartLs, Reset -> PendConOutDSPU: LS HOST3745: input=ReqOpn.Cnf, PendConOut -> XidDSPU: LS HOST3745: input=Connect.Ind, Xid -> ConnInDSPU: LS HOST3745: input=Connected.Ind, ConnIn -> ConnectedDSPU: PU HOST3745: input=Actpu, Reset -> ActiveDSPU: LU HOST3745-2: input=uActlu, Reset -> upLuActiveDSPU: LU HOST3745-3: input=uActlu, Reset -> upLuActive...DSPU: LU HOST3745-253: input=uActlu, Reset -> upLuActiveDSPU: LU HOST3745-254: input=uActlu, Reset -> upLuActiveDSPU: LS HOST3745: input=PuStopped, Connected -> PendDiscDSPU: LS HOST3745: input=Disc.Cnf, PendDisc -> PendCloseDSPU: LS HOST3745: input=Close.Cnf, PendClose -> ResetDSPU: PU HOST3745: input=T2ResetPu, Active -> ResetDSPU: LU HOST3745-2: input=uStopLu, upLuActive -> ResetDSPU: LU HOST3745-3: input=uStopLu, upLuActive -> Reset...DSPU: LU HOST3745-253: input=uStopLu, upLuActive -> ResetDSPU: LU HOST3745-254: input=uStopLu, upLuActive -> Resetdescribes significant fields in the output shown in .
Related Commands
debug dspu activation
debug dspu packet
debug dspu tracedebug 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 command disables debugging output.
[no] debug dspu trace [name]
Syntax Description
Usage Guidelines
Use the debug dspu trace command to display all FSM state changes. To see FSM state changes only, use the 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
shows sample debug dspu trace output.
Figure 2-68 Sample Debug DSPU Trace Output
router# debug dspu traceDSPU: LS HOST3745 input = 0 ->(1,a1)DSPU: LS HOST3745 input = 5 ->(5,a6)DSPU: LS HOST3745 input = 7 ->(5,a9)DSPU: LS HOST3745 input = 9 ->(5,a28)DSPU: LU HOST3745-2 in:0 s:0->(2,a1)DSPU: LS HOST3745 input = 19 ->(8,a20)DSPU: LS HOST3745 input = 18 ->(8,a17)DSPU: LU HOST3745-3 in:0 s:0->(2,a1)DSPU: LS HOST3745 input = 19 ->(8,a20)DSPU: LS HOST3745 input = 18 ->(8,a17)DSPU: LU HOST3745-252 in:0 s:0->(2,a1)DSPU: LS HOST3745 input = 19 ->(8,a20)DSPU: LS HOST3745 input = 18 ->(8,a17)DSPU: LU HOST3745-253 in:0 s:0->(2,a1)DSPU: LS HOST3745 input = 19 ->(8,a20)DSPU: LS HOST3745 input = 18 ->(8,a17)DSPU: LU HOST3745-254 in:0 s:0->(2,a1)DSPU: LS HOST3745 input = 19 ->(8,a20)describes significant fields in the output shown in .
Related Commands
debug dspu activation
debug dspu packet
debug dspu statedebug 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.
[no] debug eigrp fsm
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
shows sample debug eigrp fsm output.
Figure 2-69 Sample Debug EIGRP FSM Output
router# debug eigrp fsmDUAL: dual_rcvupdate(): 172.25.166.0 255.255.255.0 via 0.0.0.0 metric 750080/0DUAL: Find FS for dest 172.25.166.0 255.255.255.0. FD is 4294967295, RD is 4294967295 foundDUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0DUAL: dual_rcvupdate(): 192.168.4.0 255.255.255.0 via 0.0.0.0 metric 4294967295/4294967295DUAL: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295DUAL: 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.0DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0Explanations for individual lines of output from follow.
In the first line of , 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.
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: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295The following output indicates the route DUAL successfully installed into the routing table.
DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0The 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.0DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0debug eigrp packet
Use the debug eigrp packet EXEC command to display general debugging information. The no form of this command disables debugging output.
[no] debug eigrp packet
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
shows sample debug eigrp packet output.
Figure 2-70 Sample Debug EIGRP Packet Output
router# debug eigrp packetEIGRP: Sending HELLO on Ethernet0/1AS 109, Flags 0x0, Seq 0, Ack 0EIGRP: Sending HELLO on Ethernet0/1AS 109, Flags 0x0, Seq 0, Ack 0EIGRP: Sending HELLO on Ethernet0/1AS 109, Flags 0x0, Seq 0, Ack 0EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,AS 109, Flags 0x1, Seq 1, Ack 0EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,AS 109, Flags 0x0, Seq 0, Ack 1EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,AS 109, Flags 0x0, Seq 0, Ack 1EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,AS 109, Flags 0x0, Seq 2, Ack 0The output shows transmission and receipt of Enhanced IGRP packets. These packet types may be HELLO, UPDATE, REQUEST, QUERY, or REPLY packets. The sequence and acknowledgment 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.
describes significant fields in the output shown in .
debug fddi smt-packets
Use the debug fddi smt-packets EXEC command to display information about Station Management (SMT) frames received by the router. The no form of this command disables debugging output.
[no] debug fddi smt-packets
Sample Display
shows sample debug fddi smt-packets output. In this example, an SMT frame has been output by Fiber Distributed Data Interface (FDDI) 1/0. The SMT frame is a next station addressing (NSA) neighbor information frame (NIF) request frame with the parameters as shown.
Figure 2-71 Sample Debug FDDI SMT Output
router# debug fddi smt-packetsSMT O: Fddi1/0, FC=NSA, DA=ffff.ffff.ffff, SA=00c0.eeee.be04,class=NIF, type=Request, vers=1, station_id=00c0.eeee.be04, len=40- code 1, len 8 -- 000000016850043F- code 2, len 4 -- 00010200- code 3, len 4 -- 00003100- code 200B, len 8 -- 0000000100000000describes the fields in the output shown in .
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.
[no] debug frame-relay
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 packet command.
Sample Display
shows sample debug frame-relay output.
Figure 2-72 Sample Debug Frame-Relay Output
router# debug frame-relaySerial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24describes significant fields shown in .
debug frame-relay callcontrol
Use the debug frame-relay callcontrol EXEC command to display Frame Relay Layer 3 (network layer) call control information. The no form of this command disables debugging output.
[no] debug frame-relay callcontrol
Usage Guidelines
The debug frame-relay callcontrol command is used specifically for observing FRF.4/Q.933 signaling messages and related state changes. The FRF.4/Q.933 specification describes a state machine for call control. The signaling code implements the state machine. The debug statements display the actual event and state combinations.
The Frame Relay switched virtual circuit (SVC) signaling subsystem is an independent software module. When used with the debug frame-relay networklayerinterface command, the debug frame-relay callcontrol command provides a better understanding of the call setup and teardown sequence. The debug frame-relay networklayerinterface command provides the details of the interactions between the signaling subsystem on the router and the Frame Relay subsystem.
Sample Display
The following state changes can be observed during a call setup on the calling party side. The debug frame-relay networklayerinterface command shows the following state changes or transitions:
STATE_NULL -> STATE_CALL_INITIATED -> STATE_CALL_PROCEEDING->STATE_ACTIVEThe following messages are samples of output generated during a call setup on the calling side:
6d20h: U0_SetupRequest: Serial06d20h: L3SDL: Ref: 1, Init: STATE_NULL, Rcvd: SETUP_REQUEST, Next: STATE_CALL_INITIATED 6d20h: U1_CallProceeding: Serial06d20h: L3SDL: Ref: 1, Init: STATE_CALL_INITIATED, Rcvd: MSG_CALL_PROCEEDING, Next:STATE_CALL_PROCEEDING6d20h: U3_Connect: Serial06d20h: L3SDL: Ref: 1, Init: STATE_CALL_PROCEEDING, Rcvd: MSG_CONNECT, Next: STATE_ACTIVE 6d20h:The following messages are samples of output generated during a call setup on the called party side. Note the following state transitions as the call goes to the active state:
STATE_NULL -> STATE_CALL_PRESENT-> STATE_INCOMING_CALL_PROCEEDING->STATE_ACTIVE1w4d: U0_Setup: Serial2/31w4d: L3SDL: Ref: 32769, Init: STATE_NULL, Rcvd: MSG_SETUP, Next: STATE_CALL_PRESENT 1w4d: L3SDL: Ref: 32769, Init: STATE_CALL_PRESENT, Rcvd: MSG_SETUP, Next:STATE_INCOMING_CALL_PROC 1w4d: L3SDL: Ref: 32769, Init: STATE_INCOMING_CALL_PROC,Rcvd: MSG_SETUP, Next: STATE_ACTIVEexplains the possible call states.
Related Commands
debug frame-relay
debug frame-relay networklayerinterfacedebug 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 form of this command disables debugging output.
[no] debug frame-relay events
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
Sample Display
shows sample debug frame-relay events output.
Figure 2-73 Sample Debug Frame-Relay Events Output
router# debug frame-relay eventsSerial2(i): reply rcvd 172.16.170.26 126Serial2(i): reply rcvd 172.16.170.28 128Serial2(i): reply rcvd 172.16.170.34 134Serial2(i): reply rcvd 172.16.170.38 144Serial2(i): reply rcvd 172.16.170.41 228Serial2(i): reply rcvd 172.16.170.65 325As shows, debug frame-relay events returns one specific message type. The first line, for example, indicates that IP address 172.16.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 informationelements
Use the debug frame-relay informationelements EXEC command to display information about Frame Relay Layer 3 (network layer) information element parsing and construction. The no form of this command disables debugging output.
[no] debug frame-relay informationelements
Usage Guidelines
Within the FRF.4/Q.933 signaling specification, messages are divided into subunits called information elements. Each information element defines parameters specific to the call. These parameters can be values configured on the router, or values requested from the network.
The debug frame-relay informationelements command shows the signaling message in hexadecimal. Use this command to determine parameters being requested and granted for a call.
Note
Note
Sample Display
shows sample debug frame-relay informationelements output. In this example, each information element has a length associated with it. For those with odd-numbered lengths, only the specified bytes are valid, and the extra byte is invalid. For example, in the message "Call Ref, length: 3, 0x0200 0x0100," only "02 00 01" is valid, the last "00" is invalid.
Figure 2-74 Sample Debug Frame-Relay Information Elements Output
lw0d# debug frame-relay informationelements1w0d: Outgoing MSG_SETUP1w0d: Dir: U --> N, Type: Prot Disc, length: 1, 0x08001w0d: Dir: U --> N, Type: Call Ref, length: 3, 0x0200 0x01001w0d: Dir: U --> N, Type: Message type, length: 1, 0x05001w0d: Dir: U --> N, Type: Bearer Capability, length: 5, 0x0403 0x88A0 0xCF001w0d: Dir: U --> N, Type: DLCI, length: 4, 0x1902 0x46A01w0d: Dir: U --> N, Type: Link Lyr Core, length: 27, 0x4819 0x090B 0x5C0B 0xDC0A1w0d: 0x3140 0x31C0 0x0B21 0x40211w0d: 0xC00D 0x7518 0x7598 0x0E091w0d: 0x307D 0x80001w0d: Dir: U --> N, Type: Calling Party, length: 12, 0x6C0A 0x1380 0x3837 0x36351w0d: 0x3433 0x32311w0d: Dir: U --> N, Type: Calling Party Subaddr, length: 4, 0x6D02 0xA0001w0d: Dir: U --> N, Type: Called Party, length: 11, 0x7009 0x9331 0x3233 0x34351w0d: 0x3637 0x386E1w0d: Dir: U --> N, Type: Called Party Subaddr, length: 4, 0x7102 0xA0001w0d: Dir: U --> N, Type: Low Lyr Comp, length: 5, 0x7C03 0x88A0 0xCE651w0d: Dir: U --> N, Type: User to User, length: 4, 0x7E02 0x0000explains the information elements in the example shown in .
Related Command
debug frame-relay lapf
Use the debug frame-relay lapf EXEC command to display Frame Relay switched virtual circuit (SVC) Layer 2 information. The no form of this command disables debugging output.
[no] debug frame-relay lapf
Usage Guidelines
Use the debug frame-relay lapf command to troubleshoot the data-link control portion of Layer 2 that runs over data-link connection identifier (DLCI) 0. Use this command only if you have a problem bringing up Layer 2. You can use the show interface serial command to determine the status of Layer 2. If it shows a Link Access Procedure, Frame Relay (LAPF) state of down, Layer 2 has a problem.
Sample Displays
shows sample debug frame-relay lapf output. In this example, a line being brought up indicates an exchange of set asynchronous balanced mode extended (SAMBE) and unnumbered acknowledgment (UA) commands. A SABME is initiated by both sides, and a UA is the response. Until the SABME gets a UA response, the line is not declared to be up. The p/f value indicates the poll/final bit setting. TX means send, and RX means receive.
Figure 2-75 Sample Debug Frame-Relay LAPF Output—SABME-UA Exchange
1w0d# debug frame-relay lapf1w0d: *LAPF Serial0 TX -> SABME Cmd p/f=11w0d: *LAPF Serial0 Enter state 51w0d: *LAPF Serial0 RX <- UA Rsp p/f=11w0d: *LAPF Serial0 lapf_ua_51w0d: *LAPF Serial0 Link up!1w0d: *LAPF Serial0 RX <- SABME Cmd p/f=11w0d: *LAPF Serial0 lapf_sabme_781w0d: *LAPF Serial0 TX -> UA Rsp p/f=1In the example shown in , a line in an up LAPF state should see a steady exchange of RR (receiver ready) messages. TX means send, RX means receive, and N(R) indicates the receive sequence number.
Figure 2-76 Sample Debug Frame-Relay LAPF Output—LAPF State
1w0d# debug frame-relay lapf1w0d: *LAPF Serial0 T203 expired, state = 71w0d: *LAPF Serial0 lapf_rr_71w0d: *LAPF Serial0 TX -> RR Rsp p/f=1, N(R)= 31w0d: *LAPF Serial0 RX <- RR Cmd p/f=1, N(R)= 31w0d: *LAPF Serial0 lapf_rr_71w0d: *LAPF Serial0 TX -> RR Rsp p/f=1, N(R)= 31w0d: *LAPF Serial0 RX <- RR Cmd p/f=1, N(R)= 31w0d: *LAPF Serial0 lapf_rr_7debug 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 of this command disables debugging output.
[no] debug frame-relay lmi [interface name]
Syntax Description
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
Sample Display
shows sample debug frame-relay lmi output.
Figure 2-77 Sample Debug Frame-Relay LMI Output
In , 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 consist of a full LMI status message that includes a description of the router's two permanent virtual circuits (PVCs).
describes significant fields in the first line of the debug frame-relay lmi output shown in .
describes significant fields in the third and fourth lines of debug frame-relay lmi output shown in .
describes significant fields in the last line of debug frame-relay lmi output shown in .
debug frame-relay networklayerinterface
Use the debug frame-relay networklayerinterface EXEC command to display Network Layer Interface (NLI) information. The no form of this command disables debugging output.
[no] debug frame-relay networklayerinterface
Usage Guidelines
The Frame Relay SVC signaling subsystem is decoupled from the rest of the router code by means of the Network Layer Interface intermediate software layer.
The debug frame-relay networklayerinterface command shows what happens within the network layer interface when a call is set up or torn down. All output that contains an NL relate to the interaction between the Q.933 signaling subsystem and the Network Layer Interface.
Note
Sample Displays
shows sample debug frame-relay networklayerinterface output. This example displays the output generated when a call is set up. shows an example of the output generated when a call is torn down.
Figure 2-78 Sample Debug Frame-Relay Network Layer Interface Output—Call Setup
1w0d# debug frame-relay networklayerinterface1w0d: NLI STATE: L3_CALL_REQ, Call ID 1 state 01w0d: NLI: Walking the event table 11w0d: NLI: Walking the event table 21w0d: NLI: Walking the event table 31w0d: NLI: Walking the event table 41w0d: NLI: Walking the event table 51w0d: NLI: Walking the event table 61w0d: NLI: Walking the event table 71w0d: NLI: Walking the event table 81w0d: NLI: Walking the event table 91w0d: NLI: NL0_L3CallReq1w0d: NLI: State: STATE_NL_NULL, Event: L3_CALL_REQ, Next: STATE_L3_CALL_REQ1w0d: NLI: Enqueued outgoing packet on holdq1w0d: NLI: Map-list search: Found maplist bermuda1w0d: daddr.subaddr 0, saddr.subaddr 0, saddr.subaddr 01w0d: saddr.subaddr 0, daddr.subaddr 0, daddr.subaddr 01w0d: nli_parameter_negotiation1w0d: NLI STATE: NL_CALL_CNF, Call ID 1 state 101w0d: NLI: Walking the event table 11w0d: NLI: Walking the event table 21w0d: NLI: Walking the event table 31w0d: NLI: NLx_CallCnf1w0d: NLI: State: STATE_L3_CALL_REQ, Event: NL_CALL_CNF, Next: STATE_NL_CALL_CNF1w0d: Checking maplist "junk"1w0d: working with maplist "bermuda"1w0d: Checking maplist "bermuda"1w0d: working with maplist "bermuda"1w0d: NLI: Emptying holdQ, link 7, dlci 100, size 104Figure 2-79 Sample Debug Frame-Relay Network Layer Interface Output—Call Teardown
1w0d# debug frame-relay networklayerinterface1w0d: NLI: L3 Call Release Req for Call ID 11w0d: NLI STATE: L3_CALL_REL_REQ, Call ID 1 state 31w0d: NLI: Walking the event table 11w0d: NLI: Walking the event table 21w0d: NLI: Walking the event table 31w0d: NLI: Walking the event table 41w0d: NLI: Walking the event table 51w0d: NLI: Walking the event table 61w0d: NLI: Walking the event table 71w0d: NLI: Walking the event table 81w0d: NLI: Walking the event table 91w0d: NLI: Walking the event table 101w0d: NLI: NLx_L3CallRej1w0d: NLI: State: STATE_NL_CALL_CNF, Event: L3_CALL_REL_REQ, Next: STATE_L3_CALL_REL_REQ1w0d: NLI: junk: State: STATE_NL_NULL, Event: L3_CALL_REL_REQ, Next: STATE_NL_NULL1w0d: NLI: Map-list search: Found maplist junk1w0d: daddr.subaddr 0, saddr.subaddr 0, saddr.subaddr 01w0d: saddr.subaddr 0, daddr.subaddr 0, daddr.subaddr 01w0d: nli_parameter_negotiation1w0d: NLI STATE: NL_REL_CNF, Call ID 1 state 01w0d: NLI: Walking the event table 11w0d: NLI: Walking the event table 21w0d: NLI: Walking the event table 31w0d: NLI: Walking the event table 41w0d: NLI: Walking the event table 51w0d: NLI: Walking the event table 61w0d: NLI: Walking the event table 71w0d: NLI: NLx_RelCnf1w0d: NLI: State: STATE_NL_NULL, Event: NL_REL_CNF, Next: STATE_NL_NULLdescribes the states and events shown in and .
Related Command
debug frame-relay packet
Use the debug frame-relay packet 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 packet [interface name [dlci value]]
Syntax Description
interface name
(Optional) Name of interface or subinterface.
dlci value
(Optional) Data link connection indentifier (DLCI) decimal value.
Usage Guidelines
This command helps you analyze the packets that are sent on a Frame Relay interface. Because the debug frame-relay packet command generates large amounts of output, only use it when traffic on the Frame Relay network is less than 25 packets per second. Use the options to limit the debugging output to a specific DLCI or interface.
To analyze the packets received on a Frame Relay interface, use the debug frame-relay command.
Sample Display
shows sample debug frame-relay packet output.
Figure 2-80 Sample Debug Frame-Relay Packet Output
As shows, debug frame-relay packet 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 describe a single Frame Relay packet that was sent out on two DLCIs.
describes significant fields shown in the first pair of output lines in .
Explanations for other lines of output shown in 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.2Serial0(o):DLCI 100 type 809B size 104The following lines describe a Frame Relay packet that went out on two different DLCIs, because two Frame Relay map entries were found:
Serial0: broadcast searchSerial0(o):DLCI 300 type 809B size 24Serial0(o):DLCI 400 type 809B size 24The following lines do not appear in . They describe a Frame Relay packet sent to a true broadcast address.
Serial1: broadcast searchSerial1(o):DLCI 400 type 800 size 288debug fras error
Use the debug fras error EXEC command to display information about Frame Relay Access Support (FRAS) protocol errors. The no form of this command disables debugging output.
[no] debug fras error
Usage Guidelines
For complete information on the FRAS process, use the debug fras message along with the debug fras error command.
Sample Display
shows sample debug fras error output. This example shows that no logical connection exists between the local station and remote station in the current setup.
Figure 2-81 Sample Debug FRAS Error Output
router# debug fras errorFRAS: No route, lmac 1000.5acc.7fb1 rmac 4fff.0000.0000, lSap=0x4, rSap=0x4FRAS: Can not find the SetupRelated Commands
debug cls message
debug fras message
debug fras statedebug fras message
Use the debug fras message EXEC command to display general information about Frame Relay Access Support (FRAS) messages. The no form of this command disables debugging output.
[no] debug fras message
Usage Guidelines
For complete information on the FRAS process, use the debug fras error along with the debug fras message command.
Sample Display
shows sample debug fras message output. This example shows incoming Cisco Link Services (CLS) primitives.
Figure 2-82 Sample Debug FRAS Message Output
router# debug fras messageFRAS: receive 4C23FRAS: receive CC09Related Commands
debug cls message
debug fras error
debug fras statedebug fras state
Use the debug fras state EXEC command to display information about Frame Relay Access Support (FRAS) data link control link state changes. The no form of this command disables debugging output.
[no] debug fras state
Sample Display
shows sample debug fras state output. This example shows the state changing from a request open station is sent state to an exchange XID state.
Possible states are the following: reset, request open station is sent, exchange xid, connection request is sent, signal station wait, connection response wait, connection response sent, connection established, disconnect wait, and number of link states.
Figure 2-83 Sample Debug FRAS State Output
router# debug fras stateFRAS: TR0 (04/04) oldstate=LS_RQOPNSTNSENT, input=RQ_OPNSTN_CNFFRAS: newstate=LS_EXCHGXIDRelated Commands
debug cls message
debug fras error
debug fras messagedebug ip drp
Use the debug ip drp EXEC command to display Director Response Protocol (DRP) information. The no form of this command disables debugging output.
[no] debug ip drp
Usage Guidelines
The debug ip drp command is used to debug the director response agent used by the Distributed Director product. The Distributed Director can be used to dynamically respond to Domain Name System (DNS) queries with the IP address of the "best" host based on various criteria.
Sample Display
shows sample debug ip drp output. This example shows the packet origination, the IP address that information is routed to, and the route metrics that were returned.
Figure 2-84 Sample Debug IP DRP Output
1d02hr# debug ip drp1d02h: DRP: received v1 packet from 172.31.232.8, via Ethernet01d02h: DRP: RTQUERY for 172.31.58.94 returned internal=0,external=0describes the fields shown in .
debug ip dvmrp
