|
|
This chapter contains an alphabetical listing of the debug commands. Documentation for each command includes a brief description of its use, command syntax, usage guidelines, sample output, and a description of that output.
Output formats vary with each debug command. Some generate a single line of output per packet, whereas others generate multiple lines of output per packet. Some generate large amounts of output; others generate only occasional output. Some generate lines of text, and others generate information in field format. Thus, the way the debug commands are documented also varies. For example, for debug commands that generate lines of text, the output is described line by line. For debug commands that generate output in field format, tables are used to describe the fields.
By default, the network server sends the output from the debug commands to the console terminal. Sending output to a terminal (virtual console) produces less overhead than sending it to the console. Use the privileged EXEC command terminal monitor to send output to a terminal. For more information about redirecting output, see the "Using Debug Commands" chapter.
Use the debug apple arp EXEC command to enable debugging of the AppleTalk Address Resolution Protocol (AARP). The no form of this command disables debugging output.
debug apple arp [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
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.
Figure 2-1 shows sample debug apple arp output.
router# debug apple arp Ether0: AARP: Sent resolve for 4160.26 Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9) Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453) 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 Figure 2-1 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.26
The following line indicates that the host at network address 4160.26 has replied, giving its MAC address (0000.0c00.0453). For completeness, the message also shows the network address to which the reply was sent and its hardware MAC address (also in parentheses).
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)
Use the debug apple domain EXEC command to enable debugging of the AppleTalk domain lookups. The no form of this command disables debugging output.
debug apple domainThis command has no arguments or keywords.
EXEC
Use the debug apple domain command to observe activity between 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, updating a domain, and creating domain neighbors.
Figure 2-2 shows sample debug apple domain output intermixed with output from the debug apple remap command; the two commands show related events.
router# debug apple domain AT-REMAP: RemapProcess for net 3000 domain Domain 1 AT-REMAP: ReshuffleRemapList for subdomain 1 AT-REMAP: Could not find a remap for cable 3000-3001 AT-DOMAIN: Disabling Domain 1 [ Domain 1 ] AT-DOMAIN: Disabling interface Ethernet1 AT-DOMAIN: atdomain_DisablePort for Ethernet1 AT-DOMAIN: CleanUpDomain for domain 1 [Domain 1] AT-DOMAIN: CleanSubDomain for inbound subdomain 1 AT-REMAP: Remap for net 70 inbound subdomain 1 has been deleted AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1 AT-DOMAIN: CleanSubDomain for outbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-REMAP: Remap for net 50 outbound subdomain 1 has been deleted AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1 AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1 AT-DOMAIN: CleanUpDomain for domain 1 [Domain 1] AT-DOMAIN: CleanSubDomain for inbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1 AT-DOMAIN: CleanSubDomain for outbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1
Most lines of output in Figure 2-2 are from the debug apple domain command and are self-explanatory.
debug apple remap
Use the debug apple errors EXEC command to display errors occurring in the AppleTalk network. The no form of this command disables debugging output.
debug apple errors [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
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.
Figure 2-3 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.
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.19
As Figure 2-3 suggests, a single error message indicates zone list incompatibility; this message is sent out periodically until the condition is corrected or debug apple errors is turned off.
Most of the other messages that debug apple errors can generate are 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 encapsulation
In the following message, in addition to invalid echo packet, other possible errors are unsolicited AEP echo reply, unknown echo function, invalid ping packet, unknown ping function, and bad responder packet type.
Ethernet0: AppleTalk packet error; no source address available AT: pak_reply: dubious reply creation, dst 4160.19 AT: Unable to get a buffer for reply to 4160.19 Processing error, src 4160.12-254,dst 4160.19-254,AEP, invalid echo packet
Proc err, src 4160.12-254,dst 4160.19-254,ZIP,NetInfo Reply format is invalid
In the preceding message, in addition to NetInfo Reply format is invalid, other possible errors are NetInfoReply not for me, NetInfoReply ignored, NetInfoReply for operational net ignored, NetInfoReply from invalid port, unexpected NetInfoReply ignored, cannot establish primary zone, no primary has been set up, primary zone invalid, net information mismatch, multicast mismatch, and zones disagree.
When you turn on both debug apple errors and debug apple nbp, the following message can be generated:
Processing error, ...,NBP,NBP name invalid
In the preceding message, in addition to NBP name invalid, other possible errors are NBP type invalid, NBP zone invalid, not operational, error handling brrq, error handling proxy, NBP fwdreq unexpected, No route to srcnet, Proxy to "*" zone, Zone "*" from extended net, No zone info for "*", and NBP zone unknown.
When you turn on both debug apple errors and debug apple routing, the following message can be generated:
Processing error, ...,RTMPReq, unknown RTMP request
In the preceding message, in addition to unknown RTMP request, other possible errors are RTMP packet header bad, RTMP cable mismatch, routed RTMP data, RTMP bad tuple, and Not Req or Rsp.
Use the debug apple events EXEC command to display information about AppleTalk special events, neighbors becoming reachable/unreachable, and interfaces going up/down. Only significant events (for example, neighbor and route changes) are logged. The no form of this command disables debugging output.
debug apple events [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
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.
Figure 2-4 shows sample debug apple events output that describes a nonseed router coming up in discovery mode.
As Figure 2-4 shows, the debug apple events command is useful in tracking the discovery mode state changes through which an interface progresses. When no problems are encountered, the state changes progress as follows:
1. Line down
2. Restarting
3. Probing (for its own address [node ID] using AARP)
4. Acquiring (sending out GetNetInfo requests)
5. Requesting zones (the list of zones for its cable)
6. Verifying (that the router's configuration is correct. If not, a port configuration mismatch is declared.)
7. Checking zones (to make sure its list of zones is correct)
8. Operational (participating in routing)
Explanations for individual lines of output in Figure 2-4 follow.
The following message indicates that a port is set. In this case, the zone multicast address is being reset:
Ether0: AT: Resetting interface address filters
The following messages indicate that the router is changing to restarting mode:
%AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restarted Ether0: AppleTalk state changed; unknown -> restarting
The following message indicates that the router is probing in the startup range of network numbers (65280-65534) to discover its network number:
Ether0: AppleTalk state changed; restarting -> probing
The following message indicates that the router is enabled as a nonrouting node using a provisional network number within its startup range of network numbers. This type of message only appears if the network address the router will use differs from its configured address. This is always the case for a discovery-enabled router; it is rarely the case for a nondiscovery-enabled router.
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148
The following messages indicate that the router is sending out GetNetInfo requests to discover the default zone name and the actual network number range in which its network number can be chosen:
Ether0: AppleTalk state changed; probing -> acquiring %AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration
Now that the router has acquired the cable configuration information, the following message indicates that it restarts using that information:
Ether0: AppleTalk state changed; acquiring -> restarting
The following messages indicate that the router is probing for its actual network address:
Ether0: AppleTalk state changed; restarting -> line down Ether0: AppleTalk state changed; line down -> restarting Ether0: AppleTalk state changed; restarting -> probing
The following message indicates that the router has found an actual network address to use:
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 4160.148
The following messages indicate that the router is sending out GetNetInfo requests to verify the default zone name and the actual network number range from which its network number can be chosen:
Ether0: AppleTalk state changed; probing -> acquiring %AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration
The following message indicates that the router is requesting the list of zones for its cable:
Ether0: AppleTalk state changed; acquiring -> requesting zones
The following messages indicate that the router is sending out GetNetInfo requests to make sure its understanding of the configuration is correct:
Ether0: AppleTalk state changed; requesting zones -> verifying AT: Sent GetNetInfo request broadcast on Ethernet0
The following message indicates that the router is rechecking its list of zones for its cable:
Ether0: AppleTalk state changed; verifying -> checking zones
The following message indicates that the router is now fully operational as a routing node and can begin routing:
Ether0: AppleTalk state changed; checking zones -> operational
Figure 2-5 shows sample debug apple events output that describes a nondiscovery-enabled router coming up when no other router is on the wire.
As Figure 2-5 shows, a nondiscovery-enabled router can come up when no other router is on the wire; however, it must assume that its configuration (if accurate syntactically) is correct, because no other router can verify it. Notice that the last line in Figure 2-5 indicates this situation.
Figure 2-6 shows sample debug apple events output that describes a discovery-enabled router coming up when there is no seed router on the wire.
router# debug apple events Ether0: AT: Resetting interface address filters %AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restarted Ether0: AppleTalk state changed; unknown -> restarting Ether0: AppleTalk state changed; restarting -> probing %AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148 Ether0: AppleTalk state changed; probing -> acquiring AT: Sent GetNetInfo request broadcast on Ether0 AT: Sent GetNetInfo request broadcast on Ether0 AT: Sent GetNetInfo request broadcast on Ether0 AT: Sent GetNetInfo request broadcast on Ether0 AT: Sent GetNetInfo request broadcast on Ether0
As Figure 2-6 shows, when you attempt to bring up a nonseed router without a seed router on the wire, it never becomes operational; instead, it hangs in the acquiring mode and continues to send out periodic GetNetInfo requests.
Figure 2-7 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.
The three configuration command lines that follow indicate the part of the router's configuration that caused the configuration mismatch shown in Figure 2-7:
lestat(config)#int e 0 lestat(config-if)#apple cab 41-41 lestat(config-if)#apple zone Marketign
The router shown in Figure 2-7 had been configured with a cable range of 41-41 instead of 40-40, which would have been accurate. Additionally, the zone name was configured incorrectly; it should have been "Marketing," rather than being misspelled as "Marketign."
Use the debug apple nbp EXEC command to display debugging output from the Name Binding Protocol (NBP) routines. The no form of this command disables debugging output.
debug apple nbp [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
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.
Figure 2-8 shows sample debug apple nbp output.
router# debug apple nbp AT: NBP ctrl = LkUp, ntuples = 1, id = 77 AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW Lab AT: LkUp =:ciscoRouter@Low End SW Lab AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77 AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW Lab AT: NBP ctrl = LkUp, ntuples = 1, id = 78 AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW Lab AT: NBP ctrl = LkUp, ntuples = 1, id = 79 AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW Lab AT: NBP ctrl = LkUp, ntuples = 1, id = 83 AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW Lab AT: LkUp =:ciscoRouter@Low End SW Lab AT: NBP ctrl = LkUp, ntuples = 1, id = 84 AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW Lab AT: NBP ctrl = LkUp, ntuples = 1, id = 85 AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW Lab AT: NBP ctrl = LkUp, ntuples = 1, id = 85 AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW Lab
The first three lines in Figure 2-8 describe an NBP lookup request:
AT: NBP ctrl = LkUp, ntuples = 1, id = 77 AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW Lab AT: LkUp =:ciscoRouter@Low End SW Lab
Table 2-1 describes the fields in the first line of output shown in Figure 2-8.
| Field | Description |
|---|---|
AT: NBP | Indicates that this message describes an AppleTalk NBP packet. |
ctrl = LkUp | Identifies the type of NBP packet. Possible values include LkUp—NBP lookup request. LkUp-Reply—NBP lookup reply. |
ntuples = 1 | Indicates the number of name-address pairs in the lookup request packet. Range: 1-31 tuples. |
id = 77 | Identifies an NBP lookup request value. |
Table 2-2 describes the fields in the second line of output shown in Figure 2-8.
| Field | Description |
|---|---|
AT: | Indicates that this message describes an AppleTalk packet. |
4160.19 | Indicates the network address of the requester. |
skt 2 | Indicates the internet socket address of the requester. The responder will send the NBP lookup reply to this socket address. |
enum 0 | Indicates the enumerator field. Used to identify multiple names registered on a single socket. Each tuple is assigned its own enumerator, incrementing from 0 for the first tuple. |
name: =:ciscoRouter@Low End SW Lab | Indicates the entity name for which a network address has been requested. The AppleTalk entity name includes three components: Object (in this case, a wildcard character ( Type (in this case, ciscoRouter) Zone (in this case, Low End SW Lab) |
The third line in Figure 2-8 essentially reiterates the information in the two lines above it, indicating that a lookup request has been made regarding name-address pairs for all objects of the ciscoRouter type in the Low End SW Lab zone.
Because the router is defined as an object of type ciscoRouter in zone Low End SW Lab, the router sends an NBP lookup reply in response to this NBP lookup request. The following two lines of output from Figure 2-8 show the router's response:
AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77 AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW Lab
In the first line, ctrl = LkUp-Reply identifies this NBP packet as an NBP lookup request. The same value in the id field (id = 77) associates this lookup reply with the previous lookup request. The second line indicates that the network address associated with the router's entity name (lestat.Ether0:ciscoRouter@Low End SW Lab) is 4160.154. The fact that no other entity name/network address is listed indicates that the responder only knows about itself as an object of type ciscoRouter in zone Low End SW Lab.
Use the debug apple packet EXEC command to display per-packet debugging output. The output reports information online when a packet is received or a transmit is attempted. The no form of this command disables debugging output.
debug apple packet [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
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.
Figure 2-9 shows sample debug apple packet output.
router# debug apple packet Ether0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000 AT: src=Ethernet0:4160.47, dst=4160-4160, size=10, 2 rtes, RTMP pkt sent AT: ZIP Extended reply rcvd from 4160.19 AT: ZIP Extended reply rcvd from 4160.19 AT: src=Ethernet0:4160.47, dst=4160-4160, size=10, 2 rtes, RTMP pkt sent Ether0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000 Ether0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000
Table 2-3 describes the fields in the first line of output shown in Figure 2-9.
| Field | Description |
|---|---|
Ether0: | Name of the interface through which the router received the packet |
AppleTalk packet | Indication that this is an AppleTalk packet |
enctype SNAP | Encapsulation type for the packet |
size 60 | Size of the packet (in bytes) |
encaps000000000000000000000000 | Encapsulation |
Table 2-4 describes the fields in the second line of output shown in Figure 2-9.
| Field | Description |
|---|---|
AT: | Indication that this is an AppleTalk packet |
src = Ethernet0:4160.47 | Name of the interface sending the packet and its AppleTalk address |
dst = 4160-4160 | Cable range of the packet's destination |
size = 10 | Size of the packet (in bytes) |
2 rtes | Indication that two routes in the routing table link these two addresses |
RTMP pkt sent | The type of packet sent |
The third line in Figure 2-9 indicates the type of packet received and its source AppleTalk address. This message is repeated in the fourth line because AppleTalk hosts can send multiple replies to a given GetNetInfo request.
Use the debug apple remap EXEC command to enable debugging of the AppleTalk remap lookups. The no form of this command disables debugging output.
debug apple remapThis command has no arguments or keywords.
EXEC
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.
Figure 2-10 shows sample debug apple remap output intermixed with output from the debug apple domain command; the two commands show related events.
router# debug apple remap router# debug apple domain AT-REMAP: RemapProcess for net 3000 domain Domain 1 AT-REMAP: ReshuffleRemapList for subdomain 1 AT-REMAP: Could not find a remap for cable 3000-3001 AT-DOMAIN: Disabling Domain 1 [ Domain 1 ] AT-DOMAIN: Disabling interface Ethernet1 AT-DOMAIN: atdomain_DisablePort for Ethernet1 AT-DOMAIN: CleanUpDomain for domain 1 [Domain 1] AT-DOMAIN: CleanSubDomain for inbound subdomain 1 AT-REMAP: Remap for net 70 inbound subdomain 1 has been deleted AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1 AT-DOMAIN: CleanSubDomain for outbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-REMAP: Remap for net 50 outbound subdomain 1 has been deleted AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1 AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1 AT-DOMAIN: CleanUpDomain for domain 1 [Domain 1] AT-DOMAIN: CleanSubDomain for inbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1 AT-DOMAIN: CleanSubDomain for outbound subdomain 1 AT-DOMAIN: DeleteRemapTable for subdomain 1 AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1
Most lines of output in Figure 2-10 are from the debug apple domain command. The output from the debug apple remap command is self-explanatory.
debug apple domain
Use the debug apple routing EXEC command to enable debugging output from the Routing Table Maintenance Protocol (RTMP) routines. The no form of this command disables debugging output.
debug apple routing [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
This command can be used to monitor acquisition of routes, aging of routing table entries, and advertisement of known routes. It also reports conflicting network numbers on the same network if the network is misconfigured.
Figure 2-11 shows sample debug apple routing output.
router# debug apple routing AT: src=Ethernet0:4160.41, dst=4160-4160, size=19, 2 rtes, RTMP pkt sent AT: src=Ethernet1:41069.25, dst=41069, size=427, 96 rtes, RTMP pkt sent AT: src=Ethernet2:4161.23, dst=4161-4161, size=427, 96 rtes, RTMP pkt sent AT: Route ager starting (97 routes) AT: Route ager finished (97 routes) AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0) 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 sent
Explanations for representative lines of the debug apple routing output in Figure 2-11 follow.
Table 2-5 describes the fields in the first line of sample debug apple routing output.
| Field | Description |
|---|---|
AT: | Indicates that this is AppleTalk debugging output |
src = Ethernet0:4160.41 | Indicates the source router interface and network address for the RTMP update packet |
dst = 4160-4160 | Indicates the destination network address for the RTMP update packet |
size = 19 | Shows the size of this RTMP packet (in bytes) |
2 rtes | Indicates that this RTMP update packet includes information on two routes |
RTMP pkt sent | Indicates that this type of message describes an RTMP update packet that the router has sent (rather than one that it has received) |
The following two messages indicate that the ager has started and finished the aging process for the routing table and that this table contains 97 entries.
AT: Route ager starting (97 routes) AT: Route ager finished (97 routes)
Table 2-6 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)
| Field | Description |
|---|---|
AT: | Indicates that this is AppleTalk debugging output |
RTMP from 4160.19 | Indicates the source address of the RTMP update the router received |
new 0 | Shows the number of routes in this RTMP update packet that the router did not already know about |
old 94 | Shows the number of routes in this RTMP update packet that the router already knew about |
bad 0 | Shows the number of routes the other router indicates have gone bad |
ign 0 | Shows the number of routes the other router ignores |
dwn 0 | Shows the number of poisoned tuples included in this packet |
Use the debug apple zip EXEC command to display debugging output from the Zone Information Protocol (ZIP) routines. The no form of this command disables debugging output.
debug apple zip [type number]
type | (Optional) Interface type |
number | (Optional) Interface number |
EXEC
This command reports significant events such as the discovery of new zones and zone list queries. It generates information similar to that generated by debug apple routing, but generates it for ZIP packets instead of RTMP packets.
You can use he debug apple zip command to determine whether a ZIP storm is taking place in the AppleTalk network. You can detect the existence of a ZIP storm when you see that no router on a cable has the zone name corresponding to a network number that all the routers have in their routing tables.
Figure 2-12 shows sample debug apple zip output.
router# debug apple zip AT: Sent GetNetInfo request broadcast on Ether0 AT: Recvd ZIP cmd 6 from 4160.19-6 AT: 3 query packets sent to neighbor 4160.19 AT: 1 zones for 31902, ZIP XReply, src 4160.19 AT: net 31902, zonelen 10, name US-Florida
Explanations of the lines of output shown in Figure 2-12 follow.
The first line indicates that the router has received an RTMP update that includes a new network number and is now requesting zone information:
AT: Sent GetNetInfo request broadcast on Ether0
The second line indicates that the neighbor at address 4160.19 replies to the zone request with a default zone:
AT: Recvd ZIP cmd 6 from 4160.19-6
The third line indicates that the router responds with three queries to the neighbor at network address 4160.19 for other zones on the network:
AT: 3 query packets sent to neighbor 4160.19
The fourth line indicates that the neighbor at network address 4160.19 responds with a ZIP extended reply, indicating that one zone has been assigned to network 31902:
AT: 1 zones for 31902, ZIP XReply, src 4160.19
The fifth line indicates that the router responds that the zone name of network 31902 is US-Florida, and the zone length of that zone name is 10:
AT: net 31902, zonelen 10, name US-Florida
Use the debug arp EXEC command to display information on Address Resolution Protocol (ARP) transactions. The no form of this command disables debugging output.
debug arpThis command has no arguments or keywords.
EXEC
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.
Figure 2-13 shows sample debug arp output.
router# debug arp IP ARP: sent req src 131.108.22.7 0000.0c01.e117, dst 131.108.22.96 0000.0000.0000 IP ARP: rcvd rep src 131.108.22.96 0800.2010.b908, dst 131.108.22.7 IP ARP: rcvd req src 131.108.6.10 0000.0c00.6fa2, dst 131.108.6.62 IP ARP: rep filtered src 131.108.22.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffff IP ARP: rep filtered src 131.108.9.7 0000.0c00.6b31, dst 131.108.22.7 0800.2010.b908
In Figure 2-13, each line of output represents an ARP packet that the router sent or received. Explanations for the individual lines of output follow.
The first line indicates that the router at IP address 131.108.22.7 and MAC address 0000.0c01.e117 sent an ARP request for the MAC address of the host at 131.108.22.96. The series of zeros (0000.0000.0000) following this address indicate that the router is currently unaware of the MAC address.
IP ARP: sent req src 131.108.22.7 0000.0c01.e117, dst 131.108.22.96 \ 0000.0000.0000
The second line indicates that the router at IP address 131.108.22.7 receives a reply from the host at 131.108.22.96 indicating that its MAC address is 0800.2010.b908:
IP ARP: rcvd rep src 131.108.22.96 0800.2010.b908, dst 131.108.22.7
The third line indicates that the router receives an ARP request from the host at 131.108.6.10 requesting the MAC address for the host at 131.108.6.62:
IP ARP: rcvd req src 131.108.6.10 0000.0c00.6fa2, dst 131.108.6.62
The fourth line indicates that another host on the network attempted to send the router an ARP reply for the router's own address. The router ignores such bogus replies. Usually, this can happen if someone is running a bridge in parallel with the router and is allowing ARP to be bridged. It indicates a network misconfiguration.
IP ARP: rep filtered src 131.108.22.7 aa92.1b36.a456, dst 255.255.255.255 \ ffff.ffff.ffff
The fifth line indicates that another host on the network attempted to inform the router that it is on network 131.108.9.7, but the router does not know that that network is attached to a different router interface. The remote host (probably a PC or an X terminal) is misconfigured. If the router were to install this entry, it would deny service to the real machine on the proper cable.
IP ARP: rep filtered src 131.108.9.7 0000.0c00.6b31, dst 131.108.22.7 \ 0800.2010.b908
Use the debug atm errors EXEC command to display Asynchronous Transfer Mode (ATM) errors. The no form of this command disables debugging output.
debug atm errorsThis command has no arguments or keywords.
EXEC
Figure 2-14 shows sample debug atm errors output.
router# debug atm errors ATM(ATM2/0): Encapsulation error, link=7, host=836CA86D.
The line of output in Figure 2-14 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.
Use the debug atm events EXEC command to display ATM events. The no form of this command disables debugging output.
debug atm eventsThis command has no arguments or keywords.
EXEC
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.
Figure 2-15 shows sample debug atm events output.
router# debug atm events ATM events debugging is on RESET(ATM4/0): PLIM type is 1, Rate is 100Mbps aip_disable(ATM4/0): state=1 config(ATM4/0) aip_love_note(ATM4/0): asr=0x201 aip_enable(ATM4/0) aip_love_note(ATM4/0): asr=0x4000 aip_enable(ATM4/0): restarting VCs: 7 aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1 aip_love_note(ATM4/0): asr=0x200 aip_setup_vc(ATM4/0): vc:2 vpi:2 vci:2 aip_love_note(ATM4/0): asr=0x200 aip_setup_vc(ATM4/0): vc:3 vpi:3 vci:3 aip_love_note(ATM4/0): asr=0x200 aip_setup_vc(ATM4/0): vc:4 vpi:4 vci:4 aip_love_note(ATM4/0): asr=0x200 aip_setup_vc(ATM4/0): vc:6 vpi:6 vci:6 aip_love_note(ATM4/0): asr=0x200 aip_setup_vc(ATM4/0): vc:7 vpi:7 vci:7 aip_love_note(ATM4/0): asr=0x200 aip_setup_vc(ATM4/0): vc:11 vpi:11 vci:11 aip_love_note(ATM4/0): asr=0x200
Table 2-7 describes significant fields in the output shown in Figure 2-15.
| Field | Description |
|---|---|
PLIM type | Indicates the interface rate in Mbps. Possible values are |
state | Indicates current state of the AIP. Possible values are |
asr | Defines a bitmask, which indicates actions or completions to commands. Valid bitmask values are |
Explanations for representative lines of output in Figure 2-15 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 100Mbps
The following line indicates that the ATM Interface Processor (AIP) was given a shutdown command, but the current configuration indicates that the AIP should be up:
aip_disable(ATM4/0): state=1
The following line indicates that a configuration command has been completed by the AIP:
aip_love_note(ATM4/0): asr=0x201
The following line indicates that the AIP was given a no shutdown command to take it out of shutdown:
aip_enable(ATM4/0)
The following line indicates that the AIP detected a carrier state change. It does not indicate that the carrier is down or up, only that it has changed:
aip_love_note(ATM4/0): asr=0x4000
The following line of output indicates that the AIP enable function is restarting all PVCs automatically:
aip_enable(ATM4/0): restarting VCs: 7
The 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:1 aip_love_note(ATM4/0): asr=0x200
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.
debug atm packetThis command has no arguments or keywords.
EXEC
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.
Figure 2-16 shows sample debug atm packet output.
router# debug atm packets ATM packets debugging is on router# ATM2/0(O): VCD: 0x1,DM: 1C00, MUX, ETYPE: 0800,Length: 32 4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000 A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
Table 2-8 describes significant fields shown in Figure 2-16.
| Field | Description |
|---|---|
ATM2/0 | Indicates the interface that generated this packet. |
(O) | Indicates an output packet. (I) would mean receive packet. |
VCD: 0xn | Indicates the virtual circuit associated with this packet, where n is some value. |
DM: 0xnnnn | Indicates the descriptor mode bits on output only, where nnnn is a hexadecimal value. |
ETYPE: n | Shows the Ethernet type for this packet. |
Length: n | Shows the total length of the packet including the ATM header(s). |
The following two lines of output are the binary data, which are the contents of the protocol PDU before encapsulation at the ATM:
4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000 A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
Use the debug bri EXEC command to display debugging information on Integrated Services Digital Networks (ISDN) Basic Rate Interface (BRI) routing activity. The no form of this command disables debugging output.
debug briThis command has no arguments or keywords.
EXEC
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.
Figure 2-17 shows sample debug bri output.
Router# debug bri Basic Rate network interface debugging is on BRI: write_sid: wrote 1B for subunit 0, slot 1. BRI: write_sid: wrote 15 for subunit 0, slot 1. BRI: 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 B1 BRI: 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 B1 BRI: 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 down
Explanations for individual lines of output from Figure 2-17 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 down
The following line indicates that the channel was disabled:
BRI: disable channel B1
Lines of output not described are for use by support staff only.
debug isdn-event
debug isdn-q921
debug isdn-q931
Use the debug broadcast EXEC command to display information on MAC broadcast packets. The no form of this command disables debugging output.
debug broadcastThis command has no arguments or keywords.
EXEC
Depending on the type of interface and the type of encapsulation used on that interface, the debug broadcast command can produce a wide range of messages.
Figure 2-18 shows sample debug broadcast output. Notice how similar it is to the debug packet output.
router# debug broadcast Ethernet0: Broadcast ARPA, src 0000.0c00.6fa4, dst ffff.ffff.ffff, type 0x0800, data 4500002800000000FF11EA7B, len 60 Serial3: Broadcast HDLC, size 64, type 0x800, flags 0x8F00 Serial2: Broadcast PPP, size 128 Serial7: Broadcast FRAME-RELAY, size 174, type 0x800, DLCI 7a
Table 2-9 describes significant fields shown in Figure 2-18.
| Field | Description |
|---|---|
Name of Ethernet interface that received the packet. | |
| Indication that this packet was a broadcast packet. |
ARPA | Indication that this packet uses ARPA-style encapsulation. Possible encapsulation styles vary depending on the media command mode (MCM) and encapsulation style, as follows: Ethernet (MCM) Encapsulation Style |
| FDDI (MCM) Encapsulation Style |
| Serial (MCM) Encapsulation Style |
| Token Ring (MCM) Encapsulation Style |
| MAC address of the node generating the packet. |
| MAC address of the destination node for the packet. This address is always the MAC broadcast address. |
| Packet type (IP in this case). |
| First 12 bytes of the datagram following the MAC header. |
| Length of the message that the interface received from the wire (in bytes). |
| Length of the message that the interface received from the wire (in bytes). |
| HDLC or PPP flags field. |
| The DLCI number on Frame Relay. |
Use the debug cdp EXEC command to enable debugging of Cisco Discovery Protocol (CDP). The no form of this command disables debugging output.
debug cdp {packets | adjacency | events}
packets | Enables packet-related debugging output. |
adjacency | Enables adjacency-related debugging output. |
events | Enables output related related to error messages, such as detecting a bad checksum. |
EXEC
Use debug cdp commands to display information about CDP packet activity, activity between CDP neighbors, and various CDP events.
Figure 2-19 shows a composite sample output from debug cdp packets, debug cdp adjacency, and debug cdp events.
router# debug cdp packets CDP packet info debugging is on router# debug cdp adjacency CDP neighbor info debugging is on router# debug cdp events CDP events debugging is on CDP-PA: Packet sent out on Ethernet0 CDP-PA: Packet received from gray.cisco.com on interface Ethernet0 CDP-AD: Deleted table entry for violet.cisco.com, interface Ethernet0 CDP-AD: Interface Ethernet2 coming up CDP-EV: Encapsulation on interface Serial2 failed
The messages displayed by debug cdp commands are self-explanatory.
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.
debug channel eventsThis command has no arguments or keywords.
EXEC
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 except for a statistic message (cip_love_letter) transmitted every ten seconds. If the command generates numerous messages, they can indicate the possible source of the problems.
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.
Figure 2-20 shows sample debug channel events output.
Router# debug channel events Channel3/1: love letter received, bytes 3308 Channel3/0: love letter received, bytes 3336 cip_love_letter: recieved ll, but no cip_info Channel3/0: cip_reset(), state administratively down Channel3/0: cip_reset(), state up Channel3/0: sending nodeid Channel3/0: sending command for vc 0, CLAW path C700, device C0
Explanations for individual lines of output from Figure 2-20 follow.
The following line indicates that data was received on the CIP:
Channel3/1: love letter received, bytes 3308
The following line indicates that the interface is enabled, but there is no configuration for it. It does not normally indicate a problem, just that the route processor (RP) got statistics from the CIP but has no place to store them.
cip_love_letter: recieved ll, but no cip_info
The following line indicates that the CIP is being reset to an administrative down state:
Channel3/0: cip_reset(), state administratively down
The following line indicates that the CIP is being reset to an administrative up state:
Channel3/0: cip_reset(), state up
The following line indicates that the node id is being sent to the CIP. This information is the same as the "Local Node" information under the show extended channel slot/port subchannels command. The CIP needs this information to send to the host mainframe.
Channel3/0: sending nodeid
The following line indicates that a CLAW subchannel command is being sent from the RP to the CIP. The value vc 0 indicates that the CIP will use virual circuit number 0 with this device. The virual circuit number will also show up when using the debug channel packets command.
Channel3/0: sending command for vc 0, CLAW path C700, device C0
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.
debug channel packetsThis command has no arguments or keywords.
EXEC
The debug channel packets command displays all process-level Channel Interface Processor (CIP) packets for both outbound and and inbound packets. You will need to disable fast switching and autonomous switching to obtain debugging output. This command is useful for determining whether packets are received or transmitted correctly.
This command is valid for the Cisco 7000 series routers only.
Figure 2-21 shows sample debug channel packets output.
Router# debug channel packets Channel packets debugging is on (Channel3/0)-out size = 104, vc = 0000, type = 0800, src 198.92.0.11, dst 198.92.1.58 (Channel3/0)-in size = 48, vc = 0000, type = 0800, src 198.92.1.58, dst 198.92.15.197 (Channel3/0)-in size = 48, vc = 0000, type = 0800, src 198.92.1.58, dst 198.92.15.197 (Channel3/0)-out size = 71, vc = 0000, type = 0800, src 198.92.15.197, dst 198.92.1.58 (Channel3/0)-in size = 44, vc = 0000, type = 0800, src 198.92.1.58, dst 198.92.15.197
Table 2-10 provides explanations for individual lines of output from Figure 2-21.
| Field | Description |
|---|---|
(Channel3/0) | The interface slot and port. |
in / out | In is a packet from the mainframe to the router. Out is a packet from the router to the mainframe. |
size = | The number of bytes in the packet, including internal overhead. |
vc = | A value from 0-511 that maps to the claw interface configuration command. This information is from the MAC layer. |
type = | The encapsulation type in the MAC layer. The value 0800 indicates an IP datagram. |
src | The origin, or source, of the packet, as opposed to the previous hop address. |
dst | The destination of the packet, as opposed to the next hop address. |
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.
debug clns esis eventsThis command has no arguments or keywords.
EXEC
Figure 2-22 shows sample debug clns esis events output.
router# debug clns esis events ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30 ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150 ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20
Explanations for individual lines of output from Figure 2-22 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 30
The following line indicates that the router received a hello packet (ESH) from the ES at MAC address aa00.0400.9105 on the Ethernet1 interface. The hold time is 150 seconds.
ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
The following line indicates that the router sent an IS hello packet on the Ethernet0 interface to all ESs on the network. The router's NET address is 49.0001.AA00.6904.00, the hold time for this packet is 299 seconds, and the header length of this packet is 20 bytes.
ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20
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.
debug clns esis packetsThis command has no arguments or keywords.
EXEC
Figure 2-23 shows sample debug clns esis packets output.
router# debug clns esis packets ES-IS: ISH sent to All ESs (Ethernet0): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33 ES-IS: ISH sent to All ESs (Ethernet1): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34 ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299 ES-IS: ISH sent to All ESs (Tunnel0): NET 47.0005.80ff.ef00.0000.0001.5940.1600.O906.4023.00, HT 299, HLEN 34 IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300
Explanations for individual lines of output from Figure 2-23 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 router's NET 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 33
The following line indicates that the router has sent an IS hello packet on Ethernet1 to all ESs on the network. This hello packet indicates that the router's NET 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 34
The following line indicates that the router received a hello packet on Ethernet0 from an intermediate system, aa00.0400.6408. The hold time for this packet is 299 seconds.
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
The following line indicates that the router has sent an IS hello packet on Tunnel0 to all ESs on the network. This hello packet indicates that the router's NET 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 34
The following line indicates that on Ethernet0, the router received a hello packet from an end system with an SNPA of 0000.0c00.bda8. The hold time for this packet is 300 seconds.
IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300
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.
debug clns eventsThis command has no arguments or keywords.
EXEC
Figure 2-24 shows sample debug clns events output.
router# debug clns events
CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!
CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
CLNS: Forwarding packet size 117
from 39.0001.2222.2222.2222.00
to 49.0002.0001.AAAA.AAAA.AAAA.00
via 49.0002 (Ethernet3 0000.0c00.b5a3)
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3
Explanations for individual lines of output from Figure 2-24 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.00
via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
The following lines indicate that a CLNS echo packet 117 bytes in size is being sent from source NSAP 39.0001.2222.2222.2222.00 to destination NSAP 49.0002.0001.AAAA.AAAA.AAAA.00 via the router at NSAP 49.0002. The packet is being forwarded on the Ethernet3 interface, with a MAC address of 0000.0c00.b5a3.
CLNS: Forwarding packet size 117
from 39.0001.2222.2222.2222.00
to 49.0002.0001.AAAA.AAAA.AAAA.00
via 49.0002 (Ethernet3 0000.0c00.b5a3)
The following lines indicate that the router sent a redirect packet on the Ethernet3 interface to the NSAP 39.0001.2222.2222.2222.00 at MAC address 0000.0c00.3a18 to indicate that NSAP 49.0002.0001.AAAA.AAAA.AAAA.00 can be reached at MAC address 0000.0c00.b5a3.
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3
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.
debug clns igrp packetsThis command has no arguments or keywords.
EXEC
Figure 2-25 shows sample debug clns igrp packets output.
router# debug clns igrp packets ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1 ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51 ISO-IGRP: Originating level 1 periodic update ISO-IGRP: Advertise dest: 2222.2222.2222 ISO-IGRP: Sending update on interface: Ethernet3 ISO-IGRP: Originating level 2 periodic update ISO-IGRP: Advertise dest: 0001 ISO-IGRP: Sending update on interface: Ethernet3 ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3) ISO-IGRP: Opcode: area ISO-IGRP: Received level 2 adv for 0001 metric 1100 ISO-IGRP: Opcode: station ISO-IGRP: Received level 1 adv for 3333.3333.3333 metric 1100
Explanations for individual lines of output from Figure 2-25 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_green1
The following line indicates that the router received a hello packet from a certain network service access point (NSAP) on the Ethernet3 interface. The hold time for this information is 51 seconds.
ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51
The following lines indicate that the router is generating a Level 1 update to advertise reachability to destination NSAP 2222.2222.2222 and that it is sending that update to all systems that can be reached through the Ethernet3 interface:
ISO-IGRP: Originating level 1 periodic update ISO-IGRP: Advertise dest: 2222.2222.2222 ISO-IGRP: Sending update on interface: Ethernet3
The following lines indicate that the router is generating a Level 2 update to advertise reachability to destination area 1 and that it is sending that update to all systems that can be reached through the Ethernet3 interface:
ISO-IGRP: Originating level 2 periodic update ISO-IGRP: Advertise dest: 0001 ISO-IGRP: Sending update on interface: Ethernet3
The following lines indicate that the router received an update from NSAP 3333.3333.3333 on Ethernet3. This update indicated the area the router at this NSAP could reach.
ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3) ISO-IGRP: Opcode: area
The following lines indicate that the router received an update advertising that the source of that update can reach area 1 with a metric of 1100. A station opcode indicates that the update included system addresses.
ISO-IGRP: Received level 2 adv for 0001 metric 1100 ISO-IGRP: Opcode: station
Use the debug clns packet EXEC command to display information about packet receipt and forwarding to the next interface. The no form of this command disables debugging output.
debug clns packetThis command has no arguments or keywords.
EXEC
Figure 2-26 shows sample debug clns packet output.
router# debug clns packet
CLNS: Forwarding packet size 157
from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
CLNS: Echo PDU received on Ethernet0 from 4
7.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
Explanations for individual lines of output from Figure 2-26 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 157
from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
In the following lines, the first line indicates that the router received an Echo PDU on the specified interface from the source NSAP. The second line indicates which source NSAP is used to send a CLNS packet to the destination NSAP, as shown on the third line. The fourth line indicates the next-hop system ID, interface, and SNPA of the router interface used to forward this packet.
CLNS: Echo PDU received on Ethernet0 from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00! CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00 via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
Use the debug clns routing EXEC command to display debugging information of all Connectionless Network Service (CLNS) routing cache updates and activities involving the CLNS routing table. The no form of this command disables debugging output.
debug clns routingThis command has no arguments or keywords.
EXEC
Figure 2-27 shows sample debug clns routing output.
router# debug clns routing CLNS-RT: cache increment:17 CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002 CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06 CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
Explanations for individual lines of output from Figure 2-27 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:17
The following line indicates that a specific prefix route was added to the routing table, and indicates the next-hop system ID to that prefix route. In other words, when the router receives a packet with the prefix 47.0023.0001.0000.0000.0003.0001 in that 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.3002
The following lines indicate that the fast-switching cache entry for a certain network service access point (NSAP) has been invalidated and then deleted:
CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06 CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
This command has no arguments or keywords.
EXEC
Figure 2-28 shows sample debug compress output.
router# debug compress
DECOMPRESS xmt_paks 5 rcv_sync 5
COMPRESS xmt_paks 10 version 1
COMPRESS xmt_paks 11 version 1
DECOMPRESS xmt_paks 6 rcv_sync 6
COMPRESS xmt_paks 12 version 1
COMPRESS xmt_paks 13 version 1
DECOMPRESS xmt_paks 7 rcv_sync 7
COMPRESS xmt_paks 14 version 1
COMPRESS xmt_paks 15 version 1
Table 2-11 describes significant fields shown in Figure 2-28.
| Field | Description |
|---|---|
COMPRESS xmt_paks | The sequence count of this frame is modulo 256 (except zero only occurs on initialization). This value is part of the compression header sent with each frame. |
DECOMPRESS xmt_paks | The sequence count in the compression header received with this frame. |
DECOMPRESS rcv_sync | The received internal sequence count, which is verified against the DECOMPRESS xmt_paks count. If these counts do not match, a Link Access Procedure, Balanced (LAPB) reset will occur. On LAPB reset, a compression reinitialization occurs. Compression reinitialization initializes the dictionaries and xmt_paks and rcv_sync counts. |
Use the debug decnet adj EXEC command to display debugging information on DECnet adjacencies. The no form of this command disables debugging output.
debug decnet adjThis command has no arguments or keywords.
EXEC
Figure 2-29 shows sample debug decnet adj output.
router# debug decnet adj DECnet adjacencies debugging is on router# DNET-ADJ: Level 1 hello from 1.3 DNET-ADJ: sending hellos DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498 DNET-ADJ: Level 1 hello from 1.3 DNET-ADJ: 1.5 adjacency initializing DNET-ADJ: sending triggered hellos DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498 DNET-ADJ: Level 1 hello from 1.3 DNET-ADJ: 1.5 adjacency up DNET-ADJ: Level 1 hello from 1.5 DNET-ADJ: 1.5 adjacency down, listener timeout
Explanations for representative lines of output in Figure 2-29 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 1498
The following line indicates that the router has heard a hello from address 1.5 and is creating an adjacency entry in its table. The initial state of this adjacency will be initializing.
DNET-ADJ: 1.5 adjacency initializing
The following line indicates that the router is sending an unscheduled (triggered) hello as a result of some event, such as new adjacency being heard:
DNET-ADJ: sending triggered hellos
The following line indicates that the adjacency with 1.5 is now up, or active:
DNET-ADJ: 1.5 adjacency up
The following line indicates that the adjacency with 1.5 has timed out, because no hello has been heard from adjacency 1.5 in the time interval originally specified in the hello from 1.5:
DNET-ADJ: 1.5 adjacency down, listener timeout
The following line indicates that the router is sending an unscheduled hello, as a result of some event, such as the adjacency state changing:
DNET-ADJ: hello update triggered by state changed in dn_add_adjacency
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.
debug decnet connectsThis command has no arguments or keywords.
EXEC
When using connect packet filtering, it may be helpful to use the decnet access-group configuration command to apply the following basic access list:
access-list 300 permit 0.0 63.1023 access-list 300 permit 0.0 63.1023 eq any
You can then log all connect packets transmitted on interfaces to which you applied this list, in order to determine those elements on which your connect packets must be filtered.
Figure 2-30 shows sample debug decnet connects output.
router# debug decnet connects DNET-CON: list 300 item #2 matched src=19.403 dst=19.309 on Ethernet0: permitted srcname="RICK" srcuic=[0,017] dstobj=42 id="USER"
Table 2-12 describes significant fields shown in Figure 2-30.
| Field | Description |
|---|---|
DNET-CON: | Indicates that this is a debug decnet connects packet |
list 300 item #2 matched | Indicates that a packet matched the second item in access list 300 |
src = 19.403 | Indicates the source DECnet address for the packet |
dst = 19.309 | Indicates the destination DECnet address for the packet |
on Ethernet0: | Indicates the router interface on which the access list filtering the packet was applied |
| Indicates that the access list permitted the packet |
srcname = "RICK" | Indicates the originator user of the packet |
srcuic = [0,017] | Indicates the source UIC of the packet |
dstobj = 42 | Indicates that DECnet object 42 is the destination |
id="USER" | Indicates the access user |
Use the debug decnet events EXEC command to display debugging information on DECnet events. The no form of this command disables debugging output.
debug decnet eventsThis command has no arguments or keywords.
EXEC
Figure 2-31 shows sample debug decnet events output.
router# debug decnet events DNET: Hello from area 50 rejected - exceeded 'max area' parameter (45) DNET: Hello from area 50 rejected - exceeded 'max area' parameter (45)
Explanations for representative lines of output in Figure 2-31 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)
Use the debug decnet packet EXEC command to display debugging information on DECnet packet events. The no form of this command disables debugging output.
debug decnet packetThis command has no arguments or keywords.
EXEC
Figure 2-32 shows sample debug decnet packet output.
router# debug decnet packet DNET-PKT: src 1.4 dst 1.5 sending to PHASEV DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0
Explanations for individual lines of output from Figure 2-32 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 PHASEV
The following line indicates that the router forwarded a packet from node 1.4 to node 1.5. The packet is being sent to the next hop of 1.5 whose subnetwork point of attachment (MAC address) on that interface is 0000.3080.cf90.
DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0
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.
debug decnet routingThis command has no arguments or keywords.
EXEC
Figure 2-33 shows sample debug decnet routing output.
router# debug decnet routing DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34 DNET-RT: Sending routes DNET-RT: Sending normal routing updates on Ethernet0 DNET-RT: Sending level 1 routing updates on interface Ethernet0 DNET-RT: Level1 routes from 1.5 on Ethernet0: entry for node 5 created DNET-RT: route update triggered by after split route pointers in dn_rt_input DNET-RT: Received level 1 routing from 1.5 on Ethernet 0 at 1:18:35 DNET-RT: Sending L1 triggered routes DNET-RT: Sending L1 triggered routing updates on Ethernet0 DNET-RT: removing route to node 5
Explanations for individual lines of output from Figure 2-33 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:34
The following line indicates that the router is sending its scheduled updates on interface Ethernet 0:
DNET-RT: Sending normal routing updates on Ethernet0
The following line indicates that the route will send an unscheduled update on this interface as a result of some event. In this case, the unscheduled update is a result of a new entry created in the interface's routing table.
DNET-RT: route update triggered by after split route pointers in dn_rt_input
The following line indicates that the router sent the unscheduled update on Ethernet 0:
DNET-RT: Sending L1 triggered routes DNET-RT: Sending L1 triggered routing updates on Ethernet0
The following line indicates that the router removed the entry for node 5 because the adjacency with node 5 timed out, or the route to node 5 through a next-hop router went away:
DNET-RT: removing route to node 5
Use the debug dialer EXEC command to display debugging information about the packets that are received on a dialer interface. The no form of this command disables debugging output.
debug dialerThis command has no arguments or keywords.
EXEC
Table 2-13 describes the error messages that the debug dialer command can generate for a serial interface being used as a V.25bis dialer for dial-on-demand routing (DDR).
| Message | Description |
|---|---|
Serial 0: Dialer result = xxxxxxxxxx | This message displays the result returned from the V.25bis dialer. It is useful in debugging if calls are failing. On some hardware platforms, this message cannot be displayed due to hardware limitations. Possible values for the xxxxxxxxxx variable depend on the V.25bis device with which the router is communicating. |
Serial 0: No dialer string defined. Dialing cannot occur. | This message is displayed when a packet is received that should cause a call to be placed. However, there is no dialer string configured, so dialing cannot occur. This message usually indicates a configuration problem. |
Serial 0: Attempting to dial xxxxxxxxxx | This message indicates that a packet has been received that passes the dial-on-demand access lists. That packet causes dialing of a phone number. The xxxxxxxxxx variable is the number being called. |
Serial 0: Unable to dial xxxxxxxxxx | This message is displayed if for some reason, the phone call could not be placed. This might be due to a lack of memory, full output queues, or other problems. |
Serial 0: disconnecting call | This message is displayed when the router attempts to hang up a call. |
Serial 0: idle timeout Serial 0: re-enable timeout Serial 0: wait for carrier timeout | One of these three messages is displayed when their corresponding dialer timer expires. They are mostly informational, but are useful when debugging a disconnected call or call failure. |
When DDR is enabled on the interface, information concerning the cause of any calls (called Dialing cause) may be displayed.
The following line of output for an IP packet lists the name of the DDR interface and the source and destination addresses of the packet:
Dialing cause: Serial0: ip (s=131.108.1.111 d=131.108.2.22)
The following line of output for a bridged packet lists the DDR interface and the type of packet (in hexadecimal). For information on these packet types, see the "Ethernet Type Codes," appendix of the Router Products Command Reference publication.
Dialing cause: Serial1: Bridge (0x6005)
Use the debug dspu activation EXEC command to display information on downstream physical unit (DSPU) activation. The no form of this command disables debugging output.
debug dspu activation [name]
name | (Optional) A host or PU name designation. |
EXEC
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.
Figure 2-34 shows sample debug dspu activation output. Not all intermediate numbers are shown for the "activated" and "deactivated" logical unit (LU) address ranges.
router# debug dspu activation DSPU: LS HOST3745 connected DSPU: PU HOST3745 activated DSPU: LU HOST3745-2 activated DSPU: LU HOST3745-3 activated . . . DSPU: LU HOST3745-253 activated DSPU: LU HOST3745-254 activated DSPU: LU HOST3745-2 deactivated DSPU: LU HOST3745-3 deactivated . . . DSPU: LU HOST3745-253 deactivated DSPU: LU HOST3745-254 deactivated DSPU: LS HOST3745 disconnected DSPU: PU HOST3745 deactivated
Table 2-14 describes significant fields in the output shown in Figure 2-34.
| Field | Description |
|---|---|
DSPU | Downstream PU debug message. |
LS | A link station (LS) event triggered the message. |
PU | A PU event triggered the message. |
LU | A logical unit (LU) event triggered the message. |
HOST3745 | Host name or PU name. |
HOST3745-253 | Host name or PU name and the LU address, separated by a colon. |
connected | Event that occured to trigger the message. |
debug dspu packet
debug dspu state
debug dspu trace
Use the debug dspu packet EXEC command to display information on downstream physical unit (DSPU) packet. The no form of this command disables debugging output.
debug dspu packet [name]
name | (Optional) A host or PU name designation. |
EXEC
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.
Figure 2-35 shows sample debug dspu packet output.
router# debug dspu packet
DSPU: Rx: PU HOST3745 data length 12 data:
2D0003002BE16B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
2D0000032BE1EB80 000D020100850000 000C060000010000 00
DSPU: Rx: PU HOST3745 data length 12 data:
2D0004002BE26B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
2D0000042BE2EB80 000D020100850000 000C060000010000 00
Table 2-15 describes significant fields in the output shown in Figure 2-35.
| Field | Description |
|---|---|
DSPU: Rx: | Received frame (packet) from the remote PU to the router PU. |
DSPU: Tx: | Transmitted frame (packet) from the router PU to the remote PU. |
PU HOST3745 | Host name or PU associated with the transmit or receive. |
data length 12 data: | Number of bytes of data, followed by up to 128 bytes of displayed data. |
debug dspu activation
debug dspu state
debug dspu trace
Use the debug dspu state EXEC command to display information on downstream physical unit (DSPU) finite state machine (FSM) state changes. The no form of this command disables debugging output.
debug dspu state [name]
name | (Optional) A host or PU name designation. |
EXEC
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.
Figure 2-36 shows sample debug dspu state output. Not all intermediate numbers are shown for the "activated" and "deactivated" logical unit (LU) address ranges.
router# debug dspu state DSPU: LS HOST3745: input=StartLs, Reset -> PendConOut DSPU: LS HOST3745: input=ReqOpn.Cnf, PendConOut -> Xid DSPU: LS HOST3745: input=Connect.Ind, Xid -> ConnIn DSPU: LS HOST3745: input=Connected.Ind, ConnIn -> Connected DSPU: PU HOST3745: input=Actpu, Reset -> Active DSPU: LU HOST3745-2: input=uActlu, Reset -> upLuActive DSPU: LU HOST3745-3: input=uActlu, Reset -> upLuActive . . . DSPU: LU HOST3745-253: input=uActlu, Reset -> upLuActive DSPU: LU HOST3745-254: input=uActlu, Reset -> upLuActive DSPU: LS HOST3745: input=PuStopped, Connected -> PendDisc DSPU: LS HOST3745: input=Disc.Cnf, PendDisc -> PendClose DSPU: LS HOST3745: input=Close.Cnf, PendClose -> Reset DSPU: PU HOST3745: input=T2ResetPu, Active -> Reset DSPU: LU HOST3745-2: input=uStopLu, upLuActive -> Reset DSPU: LU HOST3745-3: input=uStopLu, upLuActive -> Reset . . . DSPU: LU HOST3745-253: input=uStopLu, upLuActive -> Reset DSPU: LU HOST3745-254: input=uStopLu, upLuActive -> Reset
Table 2-15 describes significant fields in the output shown in Figure 2-36.
| Field | Descrip |
|---|