|
|
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 of the various debug commands vary. Some generate a single line of output per packet, whereas others generate multiple lines of output per packet. Some generate 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 it to a terminal. For more information about redirecting output, see the chapter, "Using Debug Commands."
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 [interface unit]| [interface unit] | interface and unit are optional arguments to specify that information for a particular interface be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit 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 1-1 shows sample debug apple arp output.
Explanations for representative lines of output in Figure 1-1 follow.
The following line of output indicates that the router has requested the hardware MAC address of the host at network address 4160.26.
Ether0: AARP: Sent resolve for 4160.26
The following line of output indicates that the host at network address 4160.26 has replied, giving its MAC address (0000.0c00.0453). For completeness, the message also shows the network address to which the reply was sent and its hardware MAC address (also in parentheses).
Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9)
The following line of output indicates that the MAC address request is complete.
Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453)
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 [interface unit]| interface unit | interface and unit are optional arguments to specify that information for a particular interface be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit number. |
EXEC
In a stable AppleTalk network, the debug apple errors command produce little output.
To solve encapsulation problems, enable debug apple errors and debug apple packet together.
Figure 1-2 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.
As Figure 1-2 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
The debug apple errors command can print out additional messages when other debugging commands are also turned on. When you turn on both debug apple errors and debug apple events, the following message can be generated:
Proc err, src 4160.12-254,dst 4160.19-254,ZIP,NetInfo Reply format is invalid
In the previous 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 previous 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 previous 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 [interface unit]| interface unit | (Optional.) Information for a particular interface is to be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit 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, however, the command generates numerous messages, they can indicate where the problems might lie.
When configuring or making changes to a router or interface for AppleTalk, enable debug apple events. Doing so will alert 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 on- and off-line) is occurring. If flapping is excessive, look for routers that only support 254 networks.
When you enable debug apple events, you also will see any messages that the configuration command apple event-logging normally displays. Turning on debug apple events, however, will not cause apple event-logging to be maintained in nonvolatile memory. Only turning on apple event-logging explicitly will store it in nonvolatile memory. Furthermore, if apple event-logging is already enabled, turning on or off debug apple events will not affect apple event-logging.
Figure 1-3 shows sample debug apple events output that describes a nonseed router coming up in discovery mode.
As Figure 1-3 shows, the debug apple events command can be useful in tracking the discovery mode state changes through which an interface progresses. When no problems are encountered, the state changes progress as follows:
Explanations for individual lines of output in Figure 1-3 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 1-4 shows sample debug apple events output that describes a nondiscovery-enabled router coming up when no other router is on the wire.
As Figure 1-4 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 1-4 indicates this situation.
Figure 1-5 shows sample debug apple events output that describes a discovery-enabled router coming up when there is no seed router on the wire.
As Figure 1-5 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 1-6 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 1-6.
lestat(config)#int e 0
lestat(config-if)#apple cab 41-41
lestat(config-if)#apple zone Marketign
The router shown in Figure 1-6 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 [interface unit]| interface unit | (Optional.) Information for a particular interface is to be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit 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 1-7 shows sample debug apple nbp output.
The first three lines in Figure 1-7 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 1-1 describes the fields in the first line of output shown in Figure 1-7.
| 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 | Value that identifies the NBP lookup request. |
Table 1-2 describes the fields in the second line of output shown in Figure 1-7.
| Field | Description |
|---|---|
| AT: | Indicates that this message describes an AppleTalk packet. |
| 4160.19 | Network address of the requester. |
| skt 2 | Internet socket address of the requester. The responder will send the NBP lookup reply to this socket address. |
| enum 0 | 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 | 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 1-7 essentially reiterates the information in the two lines above it, indicating that a lookup request has been made regarding name-address pairs for all objects of the ciscoRouter type in the Low End SW Lab zone.
Since the router is defined as an object of type ciscoRouter in zone Low End SW Lab, it sends an NBP lookup reply in response to this NBP lookup request. The following two lines of output from Figure 1-7 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 [interface unit]| interface unit | (Optional.) Information for a particular interface is to be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit number. |
EXEC
This command allows you to monitor the types of packets being slow switched. It will display 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 1-8 shows sample debug apple packet output.
Table 1-3 describes the fields in the first line of output shown in Figure 1-8.
| Field | Description |
|---|---|
| Ether0: | Name of the interface through which the router received the packet. |
| AppleTalk packet | Indicates that this is an AppleTalk packet. |
| enctype SNAP | Encapsulation type for the packet. |
| size 60 | Size of the packet (in bytes). |
| encaps000000000000000000000000 | Encapsulation. |
Table 1-4 describes the fields in the second line of output shown in Figure 1-8.
| Field | Description |
|---|---|
| AT: | Indicates that this is an AppleTalk packet. |
| src = Ethernet0:4160.47 | Name of the interface sending the packet, as well as its AppleTalk address. |
| dst = 4160-4160 | Cable range of the packet's destination. |
| size = 10 | Size of the packet (in bytes). |
| 2 rtes | Indicates that there are two routes in the routing table that link these two addresses. |
| RTMP pkt sent | Indicates the type of packet sent. |
The third line in Figure 1-8 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 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 [interface unit]| [interface unit] | interface and unit are optional arguments to specify that information for a particular interface be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit 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 1-9 shows sample debug apple routing output.
Explanations for representative lines of the debug apple routing output in Figure 1-9 follow.
Table 1-5 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)
Table 1-5 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 | Indicates the number of routes in this RTMP update packet that the router did not already know about. |
| old 94 | Indicates the number of routes in this RTMP update packet that the router already knew about. |
| bad 0 | Number of routes the other router indicates have gone bad. |
| ign 0 | Number of routes the other router indicates it does not care about. |
| dwn 0 | 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 [interface unit]| interface unit | (Optional.) Information for a particular interface is to be displayed. For example, Ethernet0 specifies the first Ethernet interface; Ethernet1 specifies the second Ethernet interface. If you include this parameter, you must specifiy both the interface type and unit number. |
EXEC
This command reports significant events such as 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.
The debug apple zip command can be used to determine whether a ZIP storm is taking place in the AppleTalk network. You can detect the existence of a ZIP storm when you see that no router on a cable has the zone name corresponding to a network number that all the routers have in their routing tables.
Figure 1-10 shows sample debug apple zip output.
Explanations of the lines of output shown in Figure 1-10 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-Orlando, and the zone length of that zone name is 10.
AT: net 31902, zonelen 10, name US-Orlando
Use the debug arp EXEC command to display information on Address Resolution Protocol (ARP) protocol 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 or not the router is sending or receiving ARPs.
Figure 1-11 shows sample debug arp output.
In Figure 1-11, 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 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 1-12 shows sample debug broadcast output. Notice how similar it is to the debug packet output.
Table 1-7 describes significant fields shown in Figure 1-12.
Use the debug clns esis events EXEC command to displays uncommon 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 1-13 shows sample debug clns esis events output.
Explanations for individual lines of output from Figure 1-13 follow.
The following line of output 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 for this entry is 30.
ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30
The following line of output 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 (or number of seconds to consider this entry valid before deleting it) is 150.
ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
The following line of output 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 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 1-14 shows sample debug clns esis packets output.
Explanations for individual lines of output from Figure 1-14 follow.
The following line of output 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 information 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 of output 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 information 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 of output indicates that the router received a hello packet on Ethernet0 from an intermediate system aa00.0400.6408. The hold time for this information is 299 seconds.
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
The following line of output 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 information 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 of output 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 information 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 occuring at the router. The no form of this command disables debugging output.
debug clns eventsThis command has no arguments or keywords.
EXEC
Figure 1-15 shows sample debug clns events output.
Explanations for individual lines of output from Figure 1-15 follow.
The following line of output indicates that the router received an echo PDU on Ethernet3 from source 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 of output 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 of output 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 of output 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 1-16 shows sample debug clns igrp packets output.
Explanations for individual lines of output from Figure 1-16 follow.
The following line of output 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 of output indicates that the router received a hello packet from a certain 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 of output 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 of output 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 of output 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 of output 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 1-17 shows sample debug clns packet output.
Explanations for individual lines of output from Figure 1-17 follow.
In the following lines of output, the first line indicates that a CLNS packet of size 157 bytes is being forwarded. The second line indicates the 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 of output, 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 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 1-18 shows sample debug clns routing output.
Explanations for individual lines of output from Figure 1-18 follow.
The following line of output 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 of output 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 of output indicate that the fast-switching cache entry for a certain 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
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 then can 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 1-19 shows sample debug decnet connects output.
Table 1-8 describes significant fields shown in Figure 1-19.
| Field | Description |
|---|---|
| DNET-CON: | Indicates that this is a debug decnet connects packet. |
| list 300 item #2 matched | Indicates that a packet matched the second item in access list 300. |
| src = 19.403 | Indicates the source DECnet address for the packet. |
| dst = 19.309 | Indicates the destination DECnet address for the packet. |
| on Ethernet0: | Indicates the router interface on which the access list filtering the packet was applied. |
permitted
| Indicates that the access list permitted the packet. |
| srcname = "RICK" | Indicates the originator user of the packet. |
| 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 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 1-20 shows sample debug decnet packet output.
Explanations for individual lines of output from Figure 1-20 follow.
The following line of output indicates that the router is sending a converted packet addressed to node 1.10 to Phase V.
DNET-PKT: src 1.3 dst 1.10 sending to PHASEV
The following line of output indicates that the router forwarded a packet from node 1.3 to node 1.23.
DNET-PKT: Packet forwarde from 1.3 to 1.23
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 1-21 shows sample debug decnet routing output.
Explanations for individual lines of output from Figure 1-21 follow.
The following line of output indicates that the router is sending level 1 updates on interface Ethernet 0:
DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34
The following line of output indicates that the router is sending its scheduled updates on interface Ethernet 0:
DNET-RT: Sending normal routing updates on Ethernet0
The following line of output 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 of output 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 of output indicates that the router removed the entry for node 1.5 because the adjacency with node 1.5 timed out, or the route to node 1.5 through a next-hop router went away.
DNET-RT: removing route to node 5
Use the debug frame-relay EXEC command to display debugging information about the packets that have been received on a Frame Relay interface. The no form of this command disables debugging output.
debug frame-relayThis command has no arguments or keywords.
EXEC
This command helps you to analyze the packets that have been received. However, because the debug frame-relay command generates a lot of output, only use it when traffic on the Frame Relay network is less than 25 packets per second.
To analyze the packets that have been sent on a Frame Relay interface, use the debug frame-relay packets command.
Figure 1-22 shows sample debug frame-relay output.
Table 1-9 describes significant fields shown in Figure 1-22.
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.
debug frame-relay eventsThis command has no arguments or keywords.
EXEC
This command is useful for identifying the cause of end-to-end connection problems during the installation of a Frame Relay network or node.
Figure 1-23 shows sample debug frame-relay events output.
As Figure 1-23 shows, debug frame-relay events returns one specific message type. The first line, for example, indicates that IP address 131.108.170.26 sent a frame relay ARP reply; this packet was received as input on the Serial2 interface. The last field (126) is the DLCI to use when communicating with the responding router.
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.
debug frame-relay lmiThis command has no arguments or keywords.
EXEC
You can use this command to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly.
Figure 1-24 shows sample debug frame-relay lmi output.
In Figure 1-24, the first four lines describe an LMI exchange. The first line describes the LMI request the router has sent to the switch. The second line describes the LMI reply the router has received from the switch. The third and fourth lines describe the response to this request from the switch. This LMI exchange is followed by two similar LMI exchanges. The last six lines in Figure 1-24 comprise a full LMI status message that includes a description of the router's two Permanent Virtual Circuits (PVCs).
Table 1-10 describes significant fields in the first line of the debug frame-relay lmi output shown in Figure 1-24.
| Field | Description |
|---|---|
| Serial1(out) | Indicates that the LMI request was sent out on the Serial1 interface. |
| StEnq | Command Mode of message:
StEnq--Status Enquiry Status--Status reply |
| clock 20212760 | System clock (in milliseconds). Useful for determining whether an appropriate amount of time has transpired between events. |
| myseq 206 | The myseq counter maps to the router's CURRENT SEQ counter, as described in the Frame Relay Specification with Extensions. |
| yourseen 136 | The yourseen counter maps to the LAST RCVD SEQ counter of the switch, as described in the Frame Relay Specification with Extensions. |
| DTE up | Indicates the line protocol up/down state for the DTE (user) port. |
Table 1-11 describes significant fields in the second and third lines of debug frame-relay lmi output shown in Figure 1-24.
| Field | Description |
|---|---|
| RT IE 1 | Value of the report type information element. |
| length 1 | Length of the report type information element (in bytes). |
| type 1 | Report type in RT IE. |
| KA IE 3 | Value of the keepalive information element. |
| length 2 | Length of the keepalive information element (in bytes). |
| yourseq 138 | The yourseq counter maps to the CURRENT SEQ counter of the switch, as described in the Frame Relay Specification with Extensions. |
| myseq 206 | The myseq counter maps to the router's CURRENT SEQ counter, as described in the Frame Relay Specification with Extensions. |
Table 1-12 describes significant fields in the last line of debug frame-relay lmi output shown in Figure 1-24.
Use the debug frame-relay packets EXEC command to display information on packets that have been sent on a Frame Relay interface. The no form of this command disables debugging output.
debug frame-relay packetsThis command has no arguments or keywords.
EXEC
This command helps you to analyze the packets that have been sent on a Frame Relay interface. Because the debug frame-relay packets command generates large amount 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 received on a Frame Relay interface, use the debug frame-relay command.
Figure 1-25 shows sample debug frame-relay packets output.
As Figure 1-25 shows, debug frame-relay packets output comprises groups of output lines; each group describes a Frame Relay packet that has been sent. The number of lines in the group can vary, depending on the number of DLCIs on which the packet was sent. For example, the first two pairs of output lines describe two different packets, both of which were sent out on a single DLCI. The last three lines in Figure 1-25 describe a single Frame Relay packet that was sent out on two DLCIs.
Table 1-13 describes significant fields shown in the first pair of output lines in Figure 1-25.
The discussion that follows describes the other lines of debug frame-relay packet output shown in Figure 1-25.
The following lines of output describe a Frame Relay packet sent to a particular address; in this case AppleTalk address 10.2:
Serial0: broadcast - 0, link 809B, addr 10.2
Serial0(o):DLCI 100 type 809B size 104
The following lines of output describe a Frame Relay packet sent to a true broadcast address:
Serial1: broadcast search
Serial1(o):DLCI 400 type 800 size 288
The following lines of output describe a Frame Relay packet that went out on two different DLCIs, because two Frame Relay map entries were found:
Serial0: broadcast search
Serial0(o):DLCI 300 type 809B size 24
Serial0(o):DLCI 400 type 809B size 24
Use the debug ip icmp EXEC command to display information on ICMP transactions. The no form of this command disables debugging output.
debug ip icmpThis command has no arguments or keywords.
EXEC
This command is useful for determining whether the router is sending and/or receiving ICMP messages; for example, when troubleshooting an end-to-end connection problem.
Figure 1-26 shows sample debug ip icmp output.
Table 1-14 describes significant fields shown in the first line of debug ip icmp output shown in Figure 1-26.
Table 1-15 describes significant fields shown in the second line of debug ip icmp output in Figure 1-26.
| Field | Description |
|---|---|
| ICMP: | Indicates that this messages describes an ICMP packet. |
| src 36.56.0.202 | The address of the sender of the echo. |
| dst 131.108.16.1 | The address of the receiving router. |
| echo reply | Indicates the router received an echo reply. |
Other messages that the debug ip icmp command can generate follow.
When an IP router or host sends out an ICMP mask request, the following message is generated when the router sends a mask reply:
ICMP: sending mask reply (255.255.255.0) to 160.89.80.23 via Ethernet0
The following two lines are examples of the two forms of this message. The first form is generated when a mask reply comes in after the router sends out a mask request. The second form occurs when the router receives a mask reply with a nonmatching sequence and ID. See Appendix I of RFC 950, "Internet Standard Subnetting Procedures," for details.
ICMP: mask reply 255.255.255.0 from 160.89.80.31
ICMP: unexpected mask reply 255.255.255.0 from 160.89.80.32
The following output indicates that the router sent a redirect packet to the host at address 160.89.80.31, instructing that host to use the gateway at address 160.89.80.23 in order to reach the host at destination address 131.108.1.111:
ICMP: redirect sent to 160.89.80.31 for dest 131.108.1.111 use gw 160.89.80.23
The following message indicates that the router received a redirect packet from the host at address 160.89.80.23, instructing the router to use the gateway at address 160.89.80.28 in order to reach the host at destination address 160.89.81.34:
ICMP: redirect rcvd from 160.89.80.23 -- for 160.89.81.34 use gw 160.89.80.28
The following message is displayed when the router sends an ICMP packet to the source address (160.89.94.31 in this case) indicating that the destination address (131.108.13.33 in this case) is unreachable.:
ICMP: dst (131.108.13.33) host unreachable sent to 160.89.94.31
The following message is displayed when the router receives an ICMP packet from an intermediate address (160.89.98.32 in this case) indicating that the destination address (131.108.13.33 in this case) is unreachable:
ICMP: dst (131.108.13.33) host unreachable rcv from 160.89.98.32
Depending on the code received (as Table 1-14 describes), any of the unreachable messages can have any of the following instead of the "host" string in the message:
net
protocol
port
frag. needed and DF set
source route failed
prohibited
The following message is displayed when the TTL in the IP header reaches zero and a time exceed ICMP message is sent. The fields are self-explanatory.
ICMP: time exceeded (time to live) send to 128.95.1.4 (dest was 131.108.1.111)
The following message is generated when parameters in the IP header are corrupted in some way and the parameter problem ICMP message is sent. The fields are self-explanatory.
ICMP: parameter problem sent to 128.121.1.50 (dest was 131.108.1.111)
Based on the preceding information, the remaining output can be easily understood.
ICMP: parameter problem rcvd 160.89.80.32
ICMP: source quench rcvd 160.89.80.32
ICMP: source quench sent to 128.121.1.50 (dest was 131.108.1.111)
ICMP: sending time stamp reply to 160.89.80.45
ICMP: sending info reply to 160.89.80.12
ICMP: rdp advert rcvd type 9, code 0, from 160.89.80.23
ICMP: rdp solicit rcvd type 10, code 0, from 160.89.80.43
Use the debug ip igrp events EXEC command to display information of IGRP routing messages that indicate the source and destination of each update, as well as the number of routes in each update. Messages are not generated for each route. The no form of this command disables debugging output.
debug ip igrp events [ip-address]| ip-address | (Optional.) IP address of an IGRP neighbor. |
EXEC
If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp events output will include messages describing updates from that neighbor and updates that the router broadcasts toward that neighbor.
This command is particularly useful when there are many networks in your routing table. In this case, using debug ip igrp transaction could flood the console and make the router unusable. Use debug ip igrp events instead to display summary routing information.
Figure 1-27 shows sample debug ip igrp events output.
Figure 1-27 shows that the router has sent two updates to the broadcast address 255.255.255.255. The router also received two updates. Three lines of output describe each of these updates. Explanations for representative lines of output from Figure 1-27 follow.
The first line of output indicates whether the router sent or received the update packet, the source or destination address, and the interface through which the update was sent or received. If the update was sent, the IP address assigned to this interface is shown (in parentheses).
IGRP: sending update to 255.255.255.255 via Ethernet1 (160.89.33.8)
The second line of output summarizes the number and types of routes described in the update.
IGRP: Update contains 26 interior, 40 system, and 3 exterior routes.
The third line of output indicates the total number of routes described in the update.
IGRP: Total routes in update: 69
Use the debug ip igrp transaction EXEC command to display information on IGRP routing transactions. The no form of this command disables debugging output.
debug ip igrp transaction [ip-address]| [ip-address] | IP address of an IGRP neighbor. |
EXEC
If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp transaction output will include messages describing updates from that neighbor and updates that the router broadcasts toward that neighbor.
When there are many networks in your routing table, debug ip igrp transaction can flood the console and make the router unusable. In this case, use debug ip igrp events instead to display summary routing information.
Figure 1-28 shows sample debug ip igrp transaction output.
Figure 1-28 shows that the router being debugged has received updates from two other routers on the network. The router at source address 160.89.80.240 sent information about ten destinations in the update; the router at source address 160.89.80.28 sent information about three destinations in its update. The router being debugged also sent updates--in both cases to the broadcast address 255.255.255.255 as the destination address.
The first line in Figure 1-28 is self explanatory.
On the second line in Figure 1-28, the first field refers to the type of destination information: "subnet" (interior), "network" (system), or "exterior" (exterior). The second field is the Internet address of the destination network. The third field is the metric stored in the routing table and the metric advertised by the neighbor sending the information. "Metric ... inaccessible" usually means that the neighbor router has put the destination in holddown.
The entries in Figure 1-28 showing that the router is sending updates that are similar, except that the numbers in parentheses are the source addresses used in the IP header. A metric of 16777215 is inaccessible.
Other examples of output that the debug ip igrp transaction command can produce follow.
The following entry indicates that the routing table was updated and shows the new edition number (97 in this case) to be used in the next IGRP update:
IGRP: edition is now 97
Entries such as the following occur on startup or when some event occurs such as an interface transitioning or a user manually clearing the routing table:
IGRP: broadcasting request on Ethernet0
IGRP: broadcasting request on Ethernet1
The following type of entry can result when routing updates become corrupted between sending and receiving routers:
IGRP: bad checksum from 160.89.64.43
An entry such as the following should never appear. If it does, the receiving router has a bug in the software or a problem with the hardware. In either case, contact your technical support representative.
IGRP: system 45 from 160.89.64.234, should be system 109
Use the debug ip ospf events EXEC command to display information on OSPF-related events, such as adjacencies, flooding information, designated router selection, and SPF calculation. The no form of this command disables debugging output.
debug ip ospf eventsThis command has no arguments or keywords.
EXEC
Figure 1-29 shows sample debug ip ospf events output.
The debug ip ospf events output shown in Figure 1-29 might appear if any of the following occurs:
If a router configured for OSPF routing is not seeing an OSPF neighbor on an attached network, do the following:
In the following example line, the neighbor and this router are not part of a stub area (that is, one is a part of transit area and the other is a part of a stub area, as explained in RFC 1247).
OSPF: hello packet with mismatched E bit
Use the debug ip packet EXEC command to display general IP debugging information and IPSO security transactions. The no form of this command disables debugging output.
debug ip packet [list]| [list] | Optional IP access list that you can specify. If the datagram is not permitted by that access list, the related debugging output is suppressed. |
EXEC
If a communication session is closing when it should not be, an end-to-end connection problem can be the cause. The debug ip packet command is useful for analyzing the messages traveling between the local and remote hosts.
IP debugging information includes packets received, generated, and forwarded. Fast-switched packets do not generate messages.
IPSO security transactions include messages that describe the cause of failure each time a datagram fails a security test in the system. This information also is sent to the sending host when the router configuration allows it.
Figure 1-30 shows sample debug ip packet output.
Figure 1-30 shows two types of messages that the debug ip packet command can produce; the first line of output describes an IP packet that the router forwards, and the third line of output describes a packet that is destined for the router. In the third line of output, "rcvd 2" indicates that the router decided to receive the packet.
Table 1-16 describes the fields shown in the first line of Figure 1-30.
| Field | Description |
|---|---|
| IP: | Indicates that this is an IP packet. |
| s = 131.108.13.44 (Fddi0) | Indicates the source address of the packet and the name of the interface that received the packet. |
| d = 157.125.254.1 (Serial2) | Indicates the destination address of the packet and the name of the interface (in this case, S2) through which the packet is being sent out on the network. |
| g = 131.108.16.2 | Indicates the address of the next hop gateway. |
| forward | Indicates that the router is forwarding the packet. If a filter denies a packet, "access denied" replaces "forward," as shown in the last line of output in Figure 1-30. |
The calculation on whether to send a security error message can be somewhat confusing. It depends upon both the security label in the datagram and the label of the incoming interface. First, the label contained in the datagram is examined for anything obviously wrong. If nothing is wrong, assume it to be correct. If there is something wrong, the datagram is treated as unclassified genser. Then the label is compared with the interface range, and the appropriate action is taken as Table 1-17 describes.
| Classification | Authorities | Action Taken |
|---|---|---|
| Too low | Too low
Good Too high | No Response
No Response No Response |
| In range | Too low
Good Too high | No Response
Accept Send Error |
| Too high | Too low
In range Too high | No Response
Send Error Send Error |
The security code can only generate a few types of ICMP error messages. The only possible error messages and their meanings follow:
Use the debug ip rip EXEC command to display information on RIP routing transactions. The no form of this command disables debugging output.
debug ip ripThis command has no arguments or keywords.
EXEC
Figure 1-31 shows sample debug ip rip output.
Figure 1-31 shows that the router being debugged has received updates from one router at source address 160.89.80.28. That router sent information about five destinations in the routing table update. Notice that the fourth destination address in the update--131.108.0.0--is inaccessible because it is more than 15 hops away from the router sending the update. The router being debugged also sent updates, in both cases to broadcast address 255.255.255.255 as the destination.
The first line in Figure 1-31 is self-explanatory.
The second line in Figure 1-31 is an example of a routing table update. It shows how many hops a given Internet address is from the router.
The entries in Figure 1-31 showing that the router is sending updates are similar, except that the number in parentheses is the source address encapsulated into the IP header.
Examples of additional output that the debug ip rip command can generate follow.
Entries such as the following appear at startup or when some event occurs such as an interface transitioning or the user manually clearing the routing table:
RIP: broadcasting general request on Ethernet0
RIP: broadcasting general request on Ethernet1
The following line is self-explanatory:
RIP: received request from 160.89.80.207 on Ethernet0
An entry such as the following is most likely caused by a malformed packet from the transmitter:
RIP: bad version 128 from 160.89.80.43
Use the debug ip tcp driver EXEC command to display information on TCP driver events; for example, connections opening or closing, or packets being dropped because of full queues. The no form of this command disables debugging output.
debug ip tcp driverThis command has no arguments or keywords.
EXEC
The TCP driver is the process that the router software uses to send packet data over a TCP connection. Remote source-route bridging, STUN, and X.25 switching currently use the TCP driver.
Using the debug ip tcp driver command together with the debug ip tcp driver pak command provides the most verbose debugging output concerning TCP driver activity.
Figure 1-32 shows sample debug ip tcp driver output.
Explanations for individual lines of output from Figure 1-32 follow.
Table 1-18 describes the fields in the following line of output.
TCPDRV359CD8: Active open 160.89.80.26:0 --> 160.89.80.25:1996 OK, lport 36628
The following line of output indicates that the TCP driver user (remote source-route bridging, in this case) will allow TCP to drop the connection if excessive retransmissions occur:
TCPDRV359CD8: enable tcp timeouts
The following line of output indicates that the TCP driver user (in this case, remote source-route bridging) at IP address 160.89.80.26 (and using TCP port number 36628) is requesting that the connection to IP address 160.89.80.25 using TCP port number 1996 be aborted:
TCPDRV359CD8: 160.89.80.26:36628 --> 160.89.80.25:1996 Abort
The following line of output indicates that this connection was in fact closed due to an abort:
TCPDRV359CD8: 160.89.80.26:36628 --> 160.89.80.25:1996 DoClose tcp abort
Use the debug ip tcp driver-pak EXEC command to display information on every operation that the TCP driver performs. The no form of this command disables debugging output.
debug ip tcp driver-pakThis command has no arguments or keywords.
EXEC
This command turns on a verbose debugging by logging at least one debugging message for every packet sent or received on the TCP driver connection.
The TCP driver is the process that the router software uses to send packet data over a TCP connection. Remote source-route bridging, STUN, and X.25 switching currently use the TCP driver.
To observe the context within which certain debug ip tcp driver-pak messages occur, turn this command on in conjunction with the debug ip tcp driver command.
Figure 1-33 shows sample debug ip tcp driver-pak output.
Explanations for individual lines of output from Figure 1-33 follow.
Table 1-19 describes the fields shown in the following line of output:
TCPDRV359CD8: send 2E8CD8 (len 26) queued
The following line of output indicates that the TCP driver has sent the data that it had received from the TCP driver user, as shown in the previous line of output. The last field in the line (26) indicates that the 26 bytes of data were sent out as a single unit.
TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
The following line of output indicates that the TCP driver has received 42 bytes of data from the remote IP address. The TCP driver user (in this case, remote source-route bridging) has established an input threshold of 16 bytes for this connection. (The input threshold instructs the TCP driver to transfer data to the TCP driver user only when at least 16 bytes are present.)
TCPDRV359CD8: readf 42 bytes (Thresh 16)
Use the debug ip tcp transactions EXEC command to display information on significant TCP transactions such as state changes, retransmissions, and duplicate packets. The no form of this command disables debugging output.
debug ip tcp transactionsThis command has no arguments or keywords.
EXEC
This command is particularly useful for debugging a performance problem on a TCP/IP network that you have isolated above the data link layer.
The debug ip tcp command displays output for packets the router sends and receives, but does not display output for packets it forwards.
Figure 1-34 shows sample debug ip tcp transactions output.
Table 1-20 describes significant fields shown in Figure 1-34.
Use the debug ipx packet EXEC command to display information about packets received, transmitted, and forwarded. The no form of this command disables debugging output.
debug ipx packetThis command has no arguments or keywords.
EXEC
This command is useful for learning whether IPX packets are traveling over a router.
Figure 1-35 shows sample debug ipx packet output.
In Figure 1-35, the first line indicates that the router receives a packet from an Novell station (address 160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet to this router. In the second line, the router forwards the packet toward the Novell server (address 1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).
Table 1-21 describes significant fields shown in Figure 1-35.
| Field | Description |
|---|---|
IPX
| Shows that this is a IPX packet. |
src = 160.0260.8c4c.4f22
| Source address of the IPX packet. The Novell network number is 160. Its MAC address is 0260.8c4c.4f22. |
| dst = 1.0000.0000.0001 | Destination address for the IPX packet. The address 0000.0000.0001 is an internal MAC address, and the network number 1 is the internal network number of a Novell 3.11 server. |
packet received
| The router received this packet from a Novell station, possibly through an intermediate router. |
| gw = 183.0000.0c01.5d85 | The router is sending the packet over to the next hop router; its address of 183.0000.0c01.5d85 was learned from the IPX routing table. |
| sending packet | The router is attempting to send this packet. |
Use the debug ipx routing EXEC command todisplay information on IPX routing packets that the router sends and receives. The no form of this command disables debugging output.
debug ipx routingThis command has no arguments or keywords.
EXEC
Normally, a router or server sends out one routing update per minute. Each routing update packet can include up to 50 entries. If many networks exist on the internetwork, the router sends out multiple packets per update. For example, if a router has 120 entries in the routing table, it would send three routing update packets per update. The first routing update packet would include the first 50 entries, the second packet would include the next 50 entries, and the last routing update packet would include the last 20 entries.
Figure 1-36 shows sample debug ipx routing output.
Table 1-22 describes significant fields shown in Figure 1-36.
Use the debug ipx sap EXEC command to display information about IPX Service Advertisement Protocol (SAP) packets. The no form of this command disables debugging output.
debug ipx sapThis command has no arguments or keywords.
EXEC
Normally, a router or server sends out one SAP update per minute. Each SAP packet can include up to seven entries. If many servers are advertising on the network, the router sends out multiple packets per update. For example, if a router has 20 entries in the SAP table, it would send three SAP packets per update. The first SAP would include the first seven entries, the second SAP would include the next seven entries, and the last update would include the last six entries.
Figure 1-37 shows sample debug ipx sap output.
As Figure 1-37 shows, the debug ipx sap command generates multiple lines of output for each SAP packet--a packet summary message and a service detail message.
Explanations for representative lines of output from Figure 1-37 follow.
The first line of output displays the internal router memory address of the packet. The technical support staff uses this information in problem debugging.
NovellSAP: at 0023F778:
Table 1-23 describes the fields shown in the second line of output in Figure 1-37.
Table 1-24 describes the fields shown in the thirdand fourth lines of output in Figure 1-37.
The fifth line of output indicates that the router sent a SAP update to network 160:
NovellSAP: sending update to 160
As Figure 1-37 shows, the format for debug ipx sap output describing a SAP update the router sends is similar to that describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the following line of output indicates:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)
Table 1-25\ describes possible values for the ssoc: field.
debug ipx routing
Use the debug isdn-event EXEC command to display ISDN events occurring on the user side (on the router) of the ISDN interface. The ISDN events that may display are Q.931 events (call setup and teardown of ISDN network connections). The no form of this command disables debugging output.
debug isdn-eventThis command has no arguments or keywords.
EXEC
Although the debug information provided through the debug isdn-event command is similar to the information provided in the debug isdn-q931 command, the information is displayed in a different format. If you want to see the information displayed in the both formats, you can enable both of these commands at the same time. The displays will be intermingled.
Use the show dialer command to retrieve information about the status and configuration of the ISDN interface on the router.
Figure 1-38 shows sample debug isdn-event output of call setup events for an outgoing call.
Figure 1-39 shows sample debug isdn-event output of call setup events for an incoming call. The values used for internal puposes are unpacked information elements. The values that follow the ISDN specification are an interpretation of the unpacked information elements. Refer to Appendix B for information about these values.
Figure 1-40shows sample debug isdn-event output of call teardown events for a call that has been hung up by the other side of the connection.
Figure 1-41 shows sample debug isdn- event output of a call teardown event for an outgoing or incoming call that has been hung up by the ISDN interface on the router side.
Table 1-26 describes significant fields shown in Figure 1-38 through Figure 1-41.
Use the debug isdn-q921 EXEC command to display data link layer (Layer 2) access procedures that are taking place at the router on the D-channel (LAPD) of its Integrated Services Digital Network (ISDN) interface. The no form of this command disables debugging output.
debug isdn-q921This command has no arguments or keywords.
EXEC
The ISDN data link layer interface provided by the router conforms to the user interface specification defined by CCITT recommendation Q.921. The display information provided when you enter the debug isdn-q921 command is limited to commands and responses exchanged during peer-to-peer communication carried over the D-channel. This debug information does not include data transmitted over the B-channels that are also part of the router's ISDN interface. The peers (data link layer entities and layer management entities on the routers) communicate with each other via an ISDN switch over the D-channel.
A router can be the calling or called party of the ISDN Q.921 data link layer access procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call and the keepalives (RRs).
The debug isdn-q921 command can be used with the debug isdn-event and the debug isdn-q931 commands at the same time. The displays will be intermingled. See debug isdn-event later in this chapter for samples of combination displays.
Sample Display
Figure 1-42 shows sample debug isdn-q921 output for an outgoing call.
Figure 1-43 shows sample debug isdn-q921 output for an outgoing call.
Figure 1-44 shows sample debug isdn-q921 output for an incoming call. It is an incoming SETUP message that assumes L2 link is already estatblished to the other side.
Table 1-27 describes significant fields in Figure 1-42, Figure 1-43, and Figure 1-44.
Explanations for individual lines of output from Figure 1-42 follow.
The following lines of output indicate the message exchanges between the data link entity on the local router (user side) and the assignment source point (ASP) on the network side during the TEI assignment procedure. This assumes that the link is down and no TEI currently exists.
139.516 TX -> IDREQ ri = 48386 ai = 127 139.544 RX <- IDASSN ri = 48386 ai = 90At 139.516, the local router data link layer entity sent an Identity Request message to the network data link layer entity to request a TEI value that can be used in subsequent communication between the peer data link layer entities. The request includes a randomly generated reference number (48386) to differentiate between user devices that may be simultaneously requesting automatic TEI assignment and an action indicator of 127 to indicate that the ASP can assign any TEI value available. The ISDN user interface on the router uses automatic TEI assignment.
At 139.544, the network data link entity responds to the Identity Request message with an Identity Assigned message. The response includes the reference number (48386) previously sent in the request and TEI value (90) assigned by the ASP.
The following line of output indicates a message exchange between the layer management entity on the network side and the layer management entity on the local router (user side) during the TEI removal procedure:
139.520 RX <- IDREM ri = 0 ai = 89At 139.520, the network layer management entity sends an Identity Remove message when it determines that removal is necessary. The message includes a reference number that is always 0, because it is not responding to a request from the local router. The message also includes the TEI value (89) that is being removed because it is an old value that is no longer used.
The following lines of output indicate the message exchanges between the layer management entity on the network and the layer management entity on the local router (user side) during the TEI check procedure.
139.552 RX <- IDCKRQ ri = 0 ai = 127 139.560 TX -> IDCKRP ri = 36131 ai = 90At 139.552, the layer management entity on the network sends the Identity Check Request message to the layer management entity on the local router to check whether a TEI is in use. The message includes a reference number that is always 0 and the TEI value to check. In this case, an ai value of 127 indicates that all TEI values should be checked. At 139.560, the layer management entity on the local router responds with an Identity Check Response message indicating that TEI value 90 is currently in use.
The following lines of output indicate the messages exchanged between the data link layer entity on the local router (user side) and the data link layer on the network side to place the network side into modulo 128 multiple frame acknowledged operation. Note that the data link layer entity on the network side also can initiate the exchange.
140.560 TX -> SABMEp sapi = 0 tei = 90140.584 RX <- UAf sapi = 0 tei = 90
At 140.560, the data link layer entity on the local router sends the SABME command with a SAPI of 0 (call control procedure) for TEI 90. At 140.584, the first opportunity, the data link layer entity on the network responds with a UA response. This response indicates acceptance of the command. The data link layer entity sending the SABME command may have to send it more than once before receiving a UA response.
The following lines of output indicate the status of the data link layer entities. Both are ready to receive I frames.
150.768 TX -> RRp sapi = 0 tei = 90 nr = 1
150.788 RX <- RRf sapi = 0 tei = 90 nr = 1
These I frames are typically exchanged every 10 seconds (T203 timer).
Use the debug isdn-q931 EXEC command to display information about call setup and teardown of ISDN network connections (layer 3) between the local router (user side) and the network. The no form of this command disables debugging output.
debug isdn-q931This command has no arguments or keywords.
EXEC
The ISDN network layer interface provided by the router conforms to the user interface specification defined by CCITT recommendation Q.931 supplemented by other specifications such as for switch types VN2 and VN3.The router tracks only activities that are occurring on the user side, not the network side, of the network connection. The display information provided when you enter the debug isdn-q931 command is limited to commands and responses exchanged during peer-to-peer communication carried over the D-channel. This debug information does not include data transmitted over the B-channels, which are also part of the router's ISDN interface. The peers (network layers) communicate with each other via an ISDN switch over the D-channel.
A router can be the calling or called party of the ISDN Q.931 network connection call setup and tear- down procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call.
The debug isdn-q931 command can be used with the debug isdn-event and the debug isdn-q921 commands at the same time. The displays will be intermingled. See debug isdn-event earlier in this chapter for samples of combination displays.
Figure 1-45 shows sample debug isdn-q931 output of a call setup procedure for an outgoing call.
Figure 1-46 shows sample debug isdn-q931 output of a call setup procedure for an incoming call.
Figure 1-47 shows sample debug isdn-q931 output of a call teardown procedure from the network.
Figure 1-48 shows sample debug isdn-q931 output of a call teardown procedure from the router.
Table 1-28 describes significant fields in Figure 1-45 through Figure 1-48.
Use the debug isis adj packets EXEC command to display information on all adjacency-related activity such as hello packets sent and received and IS-IS adjacencies going up and down. The no form of this command disables debugging output.
debug isis adj packetsThis command has no arguments or keywords.
EXEC
Figure 1-49 shows sample debug isis adj packets output.
Explanations for individual lines of output from Figure 1-49 follow.
The following line of output indicates that the router received an IS-IS hello packet (IIH) on Ethernet0 from the Level 1 router (L1) at MAC address 0000.0c00.40af. The circuit type is the interface type: 1--Level 1 only; 2--Level 2 only; 3--Level 1/2.
The circuit ID is what the neighbor thinks is the designated router for the interface.
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01
The following line of output indicates that the router (configured as a Level 1 router) received on Ethernet1 an IS-IS hello packet from a Level 1 router in another area, thereby declaring an area mismatch:
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1
The following lines of output indicates that the router (configured as a Level 1/Level 2 router) sent on Ethernet1 a Level 1 IS-IS hello packet, and then a Level 2 IS-IS packet:
ISIS-Adj: Sending L1 IIH on Ethernet1
ISIS-Adj: Sending L2 IIH on Ethernet1
Use the debug isis spf statistics EXEC command to display statistical information about building routes between intermediate systems (ISs). The no form of this command disables debugging output.
debug isis spf statisticsThis command has no arguments or keywords.
EXEC
The Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol (IS-IS) provides routing between ISs by flooding the network with link-state information. IS-IS provides routing at two levels, intra-area (level 1) and intra-domain (level 2.) Level 1 routing allows level 1 ISs to communicate with other level 1 ISs in the same area. Level 2 routing allows level 2 ISs to build an interdomain backbone between level 1 areas by traversing only level 2 ISs. Level 1 ISs only need to know the path to the nearest level 2 IS in order to take advantage of the interdomain backbone created by the level 2 ISs.
The IS-IS protocol uses the Shortest Path First (SPF) routing algorithm to build level 1 and level 2 routes.The debug isis spf statistics command will provide information for determining the length of time it takes to place a level 1 IS or level 2 IS on the shortest path tree (SPT) using the IS-IS protocol.
Figure 1-50 shows sample debug isis spf statistics output.
Table 1-29 describes significant fields shown in Figure 1-50.
| Field | Description |
|---|---|
| Compute L1 SPT | Indicates that level 1 ISs are to be added to a level 1 area. |
| Timestamp | Indicates the time at which the SPF algorithm was applied. The time indicates the number of seconds that have elapsed since the system has been up and configured. |
| Complete L1 SPT | Indicates that the algorithm has completed for level 1 routing. |
| Compute time | Indicates the time it took to place the ISs on the shortest path tree (SPT). |
| nodes on SPT | Indicates the number of ISs that have been added. |
| Compute L2 SPT | Indicates that level 2 ISs are to be added to domain. |
| Complete L2 SPT | Indicates that the algorithm has completed for level 2 routing. |
Explanations for individual lines of output from Figure 1-50 follow.
The following lines of output show the statistical information available for Level 1 ISs:
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTThe output indicates that the SPF algorithm was applied 2780.328 seconds after the system was up and configured. Given the existing intra-area topology, it took 4 milliseconds to place one level 1 IS on the SPT.
The following lines of output show the statistical information available for Level 2 ISs:
ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 seconds ISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPT
This output indicates that the SPF algorithm was applied 2780.3336 seconds after the system was up and configured. Given the existing intra-domain topology, it took 56 milliseconds to place 12 level 2 ISs on the SPT.
Use the debug isis update-packets EXEC command to display various sequence number protocol data units (PDUs) and link state packets that are seen by the router. This router has been configured for IS-IS routing. The no form of this command disables debugging output.
debug isis update-packetsThis command has no arguments or keywords.
EXEC
Figure 1-51 shows sample debug isis update-packets output.
Explanations for individual lines of output from Figure 1-51 follow.
The following lines of output indicate that the router has sent a periodic level 1 and level 2 complete Sequence Number PDU on Ethernet 0.
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
The following lines of output indicate that the network service access point (NSAP) identified as 8888.8800.0181.00 has been deleted from the level 2 LSP 1600.8906.4022.00-00. The sequence number associated with this LSP is 0xE.
ISIS-Update: Updating L2 LSP
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E
The following lines of output indicate that the NSAP identified as 8888.8800.0181.00 has been added to the level 2 LSP 1600.8906.4022.00-00. The new sequence number associated with this LSP is 0x10.
ISIS-Update: Updating L1 LSP
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,
len 91
The following line of output indicates that the router has sent level 2 LSP 1600.8906.4022.00-00 with sequence number 0x10 on Tunnel0:
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0
The following lines of output indicates that a level 2 LSP could not be transmitted because it was recently transmitted:
ISIS-Update: Sending L2 CSNP on Tunnel0
ISIS-Update: Updating L2 LSP
ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)
The following lines of output indicate that a level 2 Partial Sequence Number (PSNP) PDU has been received on Tunnel0:
ISIS-Update: Updating L1 LSP
ISIS-Update: Rec L2 PSNP from 8888.8800.0181.00 (Tunnel0)
The following line of output indicates that a level 2 PSNP PDU with an entry for level 2 LSP 1600.8906.4022.00-00 has been received. This output is an acknowledgment that a previously sent LSP was received without an error.
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196
Use the debug lapb EXEC command to display all traffic for interfaces using LAPB encapsulation. The no form of this command disables debugging output.
debug lapbThis command has no arguments or keywords.
EXEC
This command displays information on the X.25 layer 2 protocol. It is useful to users who are familiar with the LAPB protocol.
You can use the debug lapb command to determine why X.25 virtual circuits or LAPB connections are going up and down. It is also useful for identifying link problems, as evidenced when show interfaces command displays a high number of rejects or frame errors over the X.25 link.
 | Caution Because the debug lapb command generates a lot of output, use it when the aggregate of all LAPB traffic on X.25 and LAPB interfaces is fewer than five frames per second. |
Figure 1-52 shows sample debug lapb output. (The numbers 1 through 6 at the top of the display have been added in order to aid documentation.)
In Figure 1-52 each line of output describes a LAPB event. There are two types of LAPB events: frame events (when a frame enters or exits the router) and timer events. In Figure 1-52, the last line describes a timer event; all of the other lines describe frame events. Table 1-30 describes the first six fields shown in Figure 1-52.
AsFigure 1-52 shows, a timer event only displays the first six fields of debug lapb output. For frame events, however, the fields that follow the sixth field document the LAPB control information present in the frame. Depending on the value of the frame type name shown in the sixth field, these fields may or may not appear. Descriptions of the fields following the first six fields shown in Figure 1-52 follow.
If the frame's Poll/Final bit is set, an indicator will be printed after the frame type name. Possible values follow:
After the Poll/Final indicator, depending on the frame type, three different types of LAPB control information can be printed.
For information frames, the value of the N(S) field and the N(R) field will be printed. The N(S) field of an information frame is the sequence number of that frame, so this field will rotate between 0 and 7 for successive outgoing information frames and (under normal circumstances) also will rotate for incoming information frame streams. The N(R) field is a "piggybacked" acknowledgment for the incoming information frame stream; it informs the other end of the link what sequence number is expected next.
RR, RNR, and REJ frames have an N(R) field, so the value of that field is printed. This field has exactly the same significance that it does in an information frame.
For the FRMR frame, the frame's three bytes of error information is printed (in hexadecimal notation).
The remaining frames do not have this data, so nothing will be printed.
For incoming frames, the last field will indicate whether the received frame was a command (C) or a response (R).
Use the debug lat packet EXEC command to display information on all LAT events. The no form of this command disables debugging output.
debug lat packetThis command has no arguments or keywords.
EXEC
For each datagram (packet) received or transmitted, a message is logged to the console.
Figure 1-53 shows sample debug lat packet output.
The following line of output describes a packet that is input to the router. Table 1-31 describes the fields in this line of output.
LAT: I int=Ethernet0, src=0800.2b11.2d13, dst=0000.0c01.7876, type=A, M=0, R=0
| Field | Description |
|---|---|
| LAT: | Indicates that this display shows LAT debugging output. |
| I | Indicates that this line of output describes a packet that is input to the router (I) or output from the router (O). |
| int = Ethernet0 | Indicates the interface on which the packet event took place. |
| src = 0800.2b11.2d13 | Indicates the source address of the packet. |
| dst = 0000.0c01.7876 | Indicates the destination address of the packet. |
| type = 0 | Indicates the message type (in hex). Possible values are:
0 = Run Circuit 1 = Start Circuit 2 = Stop Circuit A = Service Announcement C = Command D = Status E = Solicit Information F = Response Information |
The following line of output describes a packet that is output from the router. Table 1-32 describes the last three fields in this line of output.
LAT: O dst=0800.2b11.2d13, int=Ethernet0, type= A, M=0, R=0, len= 20, next 0 ref 1
| Field | Description |
|---|---|
| len= 20 | Indicates the length (hex) of the packet in bytes. |
| next 0 | Indicates the link on transmit queue. |
| ref 1 | Indicates the count of packet users. |
Use the debug lnm events EXEC command to display any unusual events that occur on a Token Ring network. These events includes such as stations reporting errors, or error thresholds being exceeded. The no form of this command disables debugging output.
debug lnm eventsThis command has no arguments or keywords.
EXEC
Figure 1-54 shows sample debug lnm events output.
Explanations for the messages shown in Figure 1-54 follow.
The following message indicates that station 0000.3001.1166 reported errors and has been added to the list of stations reporting errors. This station is located on Ring 3.
IBMNM3: Adding 0000.3001.1166 to error list
The following message indicates that station 0000.3001.1166 has passed the "early warning" threshold for error counts:
IBMNM3: Station 0000.3001.1166 going into preweight condition
The following message indicates that station 0000.3001.1166 is experiencing a severe number of errors:
IBMNM3: Station 0000.3001.1166 going into weight condition
The following message indicates that the error counts for station 0000.3001.1166 have all decayed to zero, so this station is being removed from the list of stations that have reported errors:
IBMNM3: Removing 0000.3001.1166 from error list
The following message indicates that Ring 0 has entered failure mode. This ring number is assigned internally.
LANMGR0: Beaconing is present on the ring
The following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned internally.
LANMGR0: Ring is no longer beaconing
The following message indicates that the router is beginning its attempt to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. The router attempts to contact stations that were part of the fault domain to see if they are still operating on the ring.
IBMNM3: Beaconing, Postmortem Started
The following message indicates that the router is attempting to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It heard back from station 0000.3000.1234, one of the two stations in the fault domain.
IBMNM3: Beaconing, heard from 0000.3000.1234
The following message indicates that the router is attempting to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It is initiating another attempt to contact the two stations in the fault domain.
IBMNM3: Beaconing, Postmortem Next Stage
The following output indicates that the router has attempted to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It has successfully heard back from both stations that were part of the fault domain.
IBMNM3: Beaconing, Postmortem Finished
Explanations for other messages that the debug lnm events command can generate follow.
The following message indicates that the router is out of memory:
LANMGR: memory request failed, find_or_build_station()
The following message indicates that Ring 3 is experiencing a large number of errors that cannot be attributed to any individual station:
IBMNM3: Non-isolating error threshold exceeded
The following message indicates that a station (or stations) on Ring 3 are receiving frames faster than they can be processed.
IBMNM3: Adapters experiencing congestion
The following message indicates that the beaconing has lasted for over 1 minute and is considered to be a "permanent" error:
IBMNM3: Beaconing, permanent
The following message indicates that the beaconing lasted for less than 1 minute. The router is attempting to determine whether either of the stations in the fault domain left the ring.
IBMNM: Beaconing, Destination Started
In the preceding line of output, the following can replace Started: Next State; Finished; Timed out; and Cannot find station 0000.0301.4876.
Use the debug lnm llc EXEC command to display all communication between the router/bridge and the LNMs that have connections to it. The no form of this command disables debugging output.
debug lnm llcThis command has no arguments or keywords.
EXEC
One line is displayed for each message sent or received.
Figure 1-55 shows sample debug lnm llc output.
As Figure 1-55 indicates, debug lnm llc output can vary somewhat in format. Table 1-33 describes significant fields shown in the first line of output in Figure 1-55.
Explanations for other types of messages shown in Figure 1-55 follow.
The following message indicates that the lookup for the bridge with which the LAN Manager was requesting to communicate was successful:
IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630
The following message is self-explanatory:
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0
The following message indicates that a LAN Manager has connected or disconnected from an internal bridge and that the router computes which LAN Manager is allowed to change parameters.
IBMNM: Determining new controlling LNM
The following line of output indicates which bridge in the router is the destination for the frame:
IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.
Use the debug lnm mac EXEC command to display all management communication between the router/bridge and all stations on the local Token Rings. The no form of this command disables debugging output.
debug lnm macThis command has no arguments or keywords.
EXEC
One line is displayed for each message sent or received.
Figure 1-56 shows sample debug lnm mac output.
Table 1-34 describes significant fields shown in the first line of output in Figure 1-56.
| Field | Description |
|---|---|
| LANMGR0: | LANMGR indicates that this line of output displays MAC-level debugging information. 0 indicates the number of the Token Ring interface associated with this line of debugging output. |
| RS | Indicates which function of the MAC-level software is communicating:
CRS--Configuration Report Server REM--Ring Error Monitor RPS--Ring Parameter Server RS--Ring Station |
| received | Indicates that the router received a frame. The other possible value is sending, to indicate that the router is sending a frame. |
| request address | Name of the specific frame that the router sent or received. Possible values include the following:
AMP initialize station report address report attachments report NAUN change report soft error report state request address request attachments request initialization request state ring purge SMP |
| from 4000.3040.a670 | If the router has received the frame, this address is the source address of the frame. If the router is sending the frame, this address is the destination address of the frame. |
As Figure 1-56 indicates, all debug lnm mac messages follow the format described in Table 1-34 except the following:
LANMGR2: RS start watching ring poll
LANMGR2: RS stop watching ring poll
These messages indicate that the router starts and stops receiving AMP and SMP frames. These frames are used to build a current picture of which stations are on the ring.
Use the debug local-ack state EXEC command to display the new and the old state conditions whenever there is a state change in the Local Acknowledgment state machine. The no form of this command disables debugging output.
debug local-ack stateThis command has no arguments or keywords.
EXEC
Figure 1-57 shows sample debug local-ack state output.
Table 1-35 describes significant fields shown in Figure 1-57.
| Field | Description |
|---|---|
| LACK_STATE: | Indicates that this packet describes a state change in the Local Acknowledgment state machine. |
| 2370300 | System clock. |
| hashp 2AE628 | Internal control block pointer used by technical support staff for debugging purposes. |
| old state = disconn | Indicates the old state condition in the Local Acknowledgment state machine. Possible values include:
Disconn (disconnected) awaiting LLC2 open to finish connected awaiting linkdown response |
| new state = awaiting LLC2 open to finish | Indicates the new state condition in the Local Acknowledgment state machine. Possible values include:
Disconn (disconnected) awaiting LLC2 open to finish connected awaiting linkdown response |
Use the debug netbios-name-cache EXEC command to display name caching activities on a router. The no form of this command disables debugging output.
debug netbios-name-cacheThis command has no arguments or keywords.
EXEC
Examine the display to diagnose problems in NetBIOS name caching.
Figure 1-58 illustrates a collection of sample debug netbios-name-cache display output listings.
Descriptions of selected debug netbios-name-cache output fields are provided in Table 1-36.
| Field | Description |
|---|---|
| NETBIOS | Indicates that this is a NetBIOS name caching debugging output. |
| L, U | L means lookup; U means update. |
| vrn=0 | Router determined that the packet comes from virtual ring number 0; this packet actually comes from a real Token Ring interface, because virtual ring number 0 is not valid. |
| addr=1000.4444.5555 | MAC address 1000.4444.5555 of machine being looked up in NetBIOS name cache. |
| idb=TR1 | Indicates that name of machine was learned from Token Ring interface number 1; idb translates into interface data block |
| type=1 | The type field indicates the way that the router learned about the specified machine. The possible values for type are as follows:
1 = Learned from traffic 2 = Learned from a remote peer 4, 8 = Statically entered via the router's configuration |
The following discussion briefly outlines each line shown in the example provided in Figure 1-58.
With the first line of output, the router declares that it has examined the NetBIOS name cache table for the machine name ORINDA and that the packet that prompted the lookup came from virtual ring 0. In this case, this packet comes from a real interface-- virtual ring number 0 is not valid.
NETBIOS: L checking name ORINDA, vrn=0
The following two entries indicate that there is a invalid NetBIOS entry and that the corrupted memory was detected. The invalid memory will be removed from the table; no action is needed.
NetBIOS name cache table corrupted at offset 13
NetBIOS name cache table corrupted at later offset, at location 13
The following output indicates that the router has attempted to check the NetBIOS cache table for the name ORINDA with MAC address 1000.4444.5555. This name was obtained from Token Ring interface 1. The type field indicates that the name was learned from traffic.
NETBIOS: U chk name=ORINDA, addr=1000.4444.5555, idb=TR1, vrn=0, type=1
The following display indicates that the NetBIOS name ORINDA is in the name cache table and has been updated to the current value:
NETBIOS: U upd name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
The following display indicates that the NetBIOS name ORINDA is not in the table and must be added to the table:
NETBIOS: U add name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
The following display indicates that there was insufficient cache buffer space when the router tried to add this name:
NETBIOS: U no memory to add cache entry. name=ORINDA,addr=1000.4444.5555
The following display indicates that the NetBIOS ager detects an invalid memory in the cache. The router clears the entry; no action is needed.
NETBIOS: Invalid structure detected in netbios_name_cache_ager
The following display indicates that the entry for ORINDA has been flushed from the cache table:
NETBIOS: flushed name=ORINDA, addr=1000.4444.5555
The following display indicates that the entry for ORINDA has timed out and has been flushed from the cache table:
NETBIOS: expired name=ORINDA, addr=1000.4444.5555
The following display indicates that the router has removed the ORINDA entry from its cache table:
NETBIOS: removing entry. name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0
The following display indicates that the router discarded a NetBIOS packet of type ADD_NAME, STATUS, NAME_QUERY, or ADD_GROUP. These packets are discarded when multiple copies of one of these packet types are detected during a certain period of time.
NETBIOS: Tossing ADD_NAME/STATUS/NAME/ADD_GROUP frame
The following display indicates that the system was unable to find a NetBIOS name in the cache:
NETBIOS: Lookup Failed -- not in cache
The following display indicates that the destination NetBIOS name was found in the cache but was determined to be located on the same ring from which the packet came. The router would drop this packet because it should not leave this ring.
NETBIOS: Lookup Worked, but split horizon failed
The following display indicates that the NetBIOS name was found in the cache but the router could not find the corresponding RIF. The packet will be sent as a broadcast frame.
NETBIOS: Could not find RIF entry
The following display indicates that no buffer was available to create a NetBIOS name-cache proxy. A proxy will not be created for the packet, which will be forwarded as a broadcast frame.
NETBIOS: Cannot duplicate packet in netbios_name_cache_proxy
Use the debug packet EXEC command to display information on packets that the network is unable to classify. The no form of this command disables debugging output.
debug packetThis command has no arguments or keywords.
EXEC
Figure 1-59 shows sample debug packet output. Notice how similar it is to debug broadcast output.
Table 1-37 describes significant fields shown in Figure 1-59.
Use the debug ppp EXEC command to display information on traffic and exchanges in an internetwork implementing the Point-to-Point Protocol (PPP). The no form of this command disables debugging output.
debug ppp {packet | negotiation | error | chap}| packet | Causes the debug ppp command to display PPP packets being sent and received. (This command displays low-level packet dumps.) |
| negotiation | Causes the debug ppp command to display PPP packets transmitted during PPP startup, where PPP options are negotiated |
| error | Causes the debug ppp command to display protocol errors and error statistics associated with PPP connection negotiation and operation. |
| chap | Causes the debug ppp command to display Challenge Authentication Protocol (CHAP) packet exchanges. |
EXEC
Use the debug ppp commands when trying to find the following:
Refer to Internet RFCs 1331, 1332, and 1333 for details concerning PPP-related nomenclature and protocol information.
Figure 1-60 provides a sample debug ppp packet output as seen from the Link Quality Monitor (LQM) side of the connection. This display example depicts packet exchanges under normal PPP operation.
Explanations for individual fields of output for the debug ppp packet command follow in Table 1-38.
| Field | Description |
|---|---|
| PPP | Indicates that this is PPP debugging output. |
| Serial4 | Interface number associated with this debugging information. |
| (o), O | Both indicate that this packet was detected as an output packet. |
| (i) I | Both indicate that this packet was detected as an input packet. |
| lcp_slqr() | Procedure name; running LQM, send a Link Quality Report (LQR). |
| lcp_rlqr() | Procedure name; running LQM, received an LQR. |
| input (C025) | Indicates that the router received a packet of the specified packet type (in hex). A value of C025 indicates packet of type LQM. |
| state = OPEN | PPP state; normal state is OPEN. |
| magic = D21B4 | Magic Number for indicated node; when output is indicated, this is the Magic Number of the node on which debugging is enabled. The actual Magic Number depends on whether the packet detected is indicated as I or O. |
| datagramsize = 52 | Packet length including header. |
| code = ECHOREQ(9) | Code identifies the type of packet received. Both forms of the packet, string and hexadecimal, are presented. |
| len = 48 | Packet length without header. |
| id = 3 | ID number per Link Control Protocol (LCP) packet format. |
| pkt type 0xC025 | Packet type in hexadecimal; typical packet types are C025 for LQM and C021 for LCP. |
| LCP ECHOREQ (9) | Specifies Echo Request; value in parentheses is the hexadecimal representation of the LCP type. |
| LCP ECHOREP (A) | Specifies Echo Reply; value in parentheses is the hexadecimal representation of the LCP type. |
To elaborate on what the router is displaying here, consider the partial exchange in Figure 1-61. This sequence shows that one side is using ECHO for its keepalives and the other side is using LQRs.
The following discussion briefly outlines each line of this exchange.
The first line states that the router with debugging enabled has sent an LQR to the other side of the PPP connection:
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
The next two lines indicate that the router has received a packet of type C025 (LQM) and provides details about the packet:
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
The next two lines indicate that the router received an ECHOREQ of type C021 (LCP). The other side is sending ECHOs. The router on which debugging is configured for LQM but also responds to ECHOs.
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454
Next the router is detected to have responded to the ECHOREQ with an ECHOREP and is preparing to send out an LQR:
PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
Figure 1-62 provides a sample debug ppp negotiation output. This is a normal negotiation, where both sides agree on NCP parameters. In this case, protocol type IP is proposed and acknowledged.
Explanations for key individual fields of output from the debug ppp negotiation command follow in Table 1-39.
The following discussion briefly outlines each line shown in the example provided in Figure 1-62.
The first two lines in Figure 1-62 indicate that the router is trying to bring up LCP and intends to use the indicated negotiation options (Quality Protocol and Magic Number). The value fields are the values of the options themselves. C025/3E8 translates to Quality Protocol LQM. 3E8 is the reporting period (in hundredths of a second). 3D56CAC is the value of the Magic Number for the router.
ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8
ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC
The next two lines indicate that the other side negotiated for options 4 and 5 as requested and acknowledged both. If the responding end does not support the options, a CONFREJ is sent by the responding node. If the responding end does not like the value of the option, a CONFNAK is sent with the value field modified.
ppp: received config for type = 4 (QUALITYTYPE) acked
ppp: received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)
The next three messages indicate that the router received a CONFACK from the responding side and displays accepted option values. Use the rcvd id field to verify the CONFREQ and CONFACK have the same id field.
PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5
ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025
ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CAC
The next debug ppp negotiation command output indicates that the router has IP routing enabled on this interface and that the IPCP NCP negotiated successfully.
ppp: ipcp_reqci: returning CONFACK.
In the last message, the router's state is listed as ACKSENT:
PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5\
Figure 1-63 provides a sample display output when both debug ppp packet and debug ppp negotiation output are enabled at the same time.
Figure 1-64 provides a sample debug ppp negotiation display output when the remote side of the connection is unable to respond to LQM requests.
Figure 1-65 provides a sample display output when no response is detected for configuration requests (with both debug ppp negotiation and debug ppp packet enabled).
Figure 1-66 provides a sample debug ppp error output. These messages might appear when the Quality Protocol option is enabled on an interface that is already running PPP.
Explanations for individual fields of output from debug ppp errors follow in Table 1-40.
| Field | Description |
|---|---|
| PPP | Indicates that this is PPP debugging output. |
| Serial3(i) | Interface number associated with this debugging information; indicates that this is an input packet. |
| rlqr receive failure | Indicates that the request to negotiate the Quality Protocol option is not accepted. |
| myrcvdiffp = 159 | Number of packets received over the time period. |
| peerxmitdiffp = 41091 | Number of packets sent by the remote node over this period. |
| myrcvdiffo = 2183 | Number of octets received over this period. |
| peerxmitdiffo = 1714439 | Number of octets sent by the remote node over this period. |
| threshold = 25 | The maximum error percentage acceptable on this interface. This percentage is calculated by the threshold value entered in the ppp quality number interface configuration command. A value of 100-number (100 minus number) is the maximum error percentage. In this case, a number of 75 was entered. This means that the local router must maintain a minimum 75 percent non-error percentage, or the PPP link will be considered down. |
| OutLQRs = 1 | Local router's current send LQR sequence number. |
| LastOutLQRs = 1 | The last sequence number that the remote node side has seen from the local node. |
Figure 1-67 provides a sample debug ppp chap output. When doing CHAP authentication, use this debug command to determine why an authentication fails.
In general, these messages are self-explanatory. Fields that appear in debug ppp chap displays that can show optional output are outlined in Table 1-41.
| Field | Description |
|---|---|
| Serial0 | Interface number associated with this debugging information and CHAP access session in question. |
| USERNAME pioneer not found. | The name pioneer in this example is the name received in the CHAP response. The router looks up this name in the list of usernames that are configured for the router. |
| Remote message is Unknown name | Messages that can appear are the following: No name received to authenticate Unknown name No secret for given name Short MD5 response received MD compare failed |
| code = 4 | Specific CHAP type packet detected. Possible values are as follows:
1 = Challenge 2 = Response 3 = Success 4 = Failure |
| len = 48 | Packet length without header. |
| id = 3 | ID number per Link Control Protocol (LCP) packet format. |
Use the debug rif EXEC command to display information on entries entering and leaving the RIF cache. The no form of this command disables debugging output.
debug rifThis command has no arguments or keywords.
EXEC
In order to use the debug rif command to display traffic source-routed through an interface, fast switching of SRB frames must first be disabled with the no source-bridge route-cache interface interface configuration command.
Figure 1-68 shows sample debug rif output.
Explanations for representative lines of debug rif output in Figure 1-68 follow.
The first line of output in Figure 1-68 is an example of a RIF entry for an interface configured for SDLLC or Local-Ack.
Table 1-42 describes significant fields shown in this line of debug rif output.
| Field | Description |
|---|---|
| RIF: | Indicates that this message describes RIF debugging output. |
| U chk | Update checking. The entry is being updated; the timer is set to zero (0). |
| da = 9000.5a59.04f9 | Destination MAC address. |
| sa = 0110.2222.33c1 | Source MAC address. This field contains values of zero (0000.0000.0000) in a non-SDLLC or non-Local-ack entry. |
| [4880.3201.00A1.0050] | RIF string. This field is blank (null RIF) in a non-SDLLC or non-Local-ack entry. |
| type 8 | Possible values follow:
0--Null entry 1--This entry was learned from a particular Token Ring port (interface) 2--Statically configured 4--Statically configured for a remote interface 8--This entry is to be aged 16--This entry (which has been learned from a remote interface) is to be aged 32--This entry is not to be aged 64 --This interface is to be used by LAN Network Manager (and is not to be aged) |
| on static/remote/0 | Indicates that this route was learned from a real Token Ring port, in contrast to a virtual ring. |
The second line of output in Figure 1-68 is an example of a RIF entry for an interface that is not configured for SDLLC or Local-ACK.
RIF: U chk da=0000.3080.4aed,sa=0000.0000.0000 [] type 8 on TokenRing0/0
Notice that the source address contains only zero values (0000.0000.0000), and that the RIF string is null ([ ]). The last element in the entry indicates that this route was learned from a virtual ring, rather than a real Token Ring port.
The third line of output in Figure 1-68 shows that a new entry has been added to the RIF cache:
RIF: U add 1000.5a59.04f9 [4880.3201.00A1.0050] type 8
The fourth line of output in Figure 1-68 shows that a RIF cache lookup operation has taken place:
RIF: L checking da=0000.3080.4aed, sa=0000.0000.0000
The fifth line of output in Figure 1-68 shows that a TEST response from address 9000.5a59.04f9 was inserted into the RIF cache:
RIF: rcvd TEST response from 9000.5a59.04f9
The sixth line of output in Figure 1-68 shows that the RIF entry for this route has been found and updated:
RIF: U upd da=1000.5a59.04f9,sa=0110.2222.33c1 [4880.3201.00A1.0050]
The seventh line of output in Figure 1-68 shows that an XID response from this address was inserted into the RIF cache:
RIF: rcvd XID response from 9000.5a59.04f9
The eighth line of output in Figure 1-68 shows that the router sent an XID response to this address:
SR1: sent XID response to 9000.5a59.04f9
Table 1-43 explains the other possible lines of debug rif output.
| Field | Description |
|---|---|
| RIF: L Sending XID for address | The router/bridge wanted to send a packet to address but did not find it in the RIF cache. It sent an XID explorer packet to determine which RIF it should use. The attempted packet is dropped. |
| RIF: L No buffer for XID to address | Similar to the previous description; however, a buffer in which to build the XID packet could not be obtained. |
| RIF: U remote rif too small [rif] | A packet's RIF was too short to be valid. |
| RIF: U rej address too big [rif] | A packet's RIF exceeded the maximum size allowed and was rejected. The maximum size is 18 bytes. |
| RIF: U upd interface address | The RIF entry for this router/bridge's interface has been updated. |
| RIF: U ign address interface update | A RIF entry that would have updated an interface corresponding to one of this router's interfaces. |
| RIF: U add address[rif] | The RIF entry for address has been added to the RIF cache. |
| RIF: U no memory to add rif for address | No memory to add a RIF entry for address. |
| RIF: removing rif entry for address, type code | The RIF entry for address has been forcibly removed. |
| RIF: flushed address | The RIF entry for address has been removed because of a RIF cache flush. |
| RIF: expired address | The RIF entry for address has been aged out of the RIF cache. |
Use the debug sdlc EXEC command to display information on SDLC frames received and sent by any router serial interface involved in supporting SDLC end station functions. The no form of this command disables debugging output.
debug sdlcThis command has no arguments or keywords.
EXEC
Because using this command is processor intensive, it is best to use it after hours, rather than in a production environment. It is also best to turn this command on by itself, rather than use it in conjunction with other debug commands.
Figure 1-69 shows sample debug sdlc output.
Explanations for individual lines of output from Figure 1-69 follow.
The following line of output indicates that the router is sending a Receiver Ready packet at location 4 in the code:
SDLC: Sending RR at location 4
The following line of output describes a frame input event:
Serial3: SDLC O (12495952) C2 CONNECT (2) RR P/F 6
Table 1-44 describes the fields in this line of output.
The following line of output describes a frame input event.
Serial3: SDLC I (12495964) [C2] CONNECT (2) RR P/F 0 (R) [VR: 6 VS: 0] rfp: P
In addition to the fields described in Table 1-44, output for a frame input event also includes two additional fields, as described in Table 1-45.
| Field | Description |
|---|---|
| (R) | Frame Type:
C--Command R--Response |
| VR: 6 | Receive count; range: 0-7. |
| VS: 0 | Send count; range: 0-7. |
| rfp: P | Ready for poll;
P --Idle poll (keepalive) timer is on. T--Data acknowledgment timer is on. These timers are based on the T1 timer. |
| VS: 0 | Send count; range: 0-7. |
The following line of output describes a frame timer event.
Serial3: SDLC T [C2] 12496064 CONNECT 12496064 0
Table 1-46 describes the fields in this line of output.
| Field | Description |
|---|---|
| Serial3: | Interface type and unit number reporting the frame event. |
| SDLC | Protocol providing the information. |
| T | Indicates that the timer has expired. |
| [C2] | SDLC address of this SDLC connection. |
| 12496064 | System clock. |
| CONNECT | State of the protocol when the frame event occurred. Possible values follow:
BOTHBUSY CONNECT DISCONNECT DISCSENT (disconnect sent) ERROR (FRMR frame sent) REJSENT (reject frame sent) SNRMSENT (SNRM frame sent) THEMBUSY BOTHBUSY |
| 12496064 | Top timer. |
| 0 | Retry count; default: 0. |
Use the debug sdlc local-ack EXEC command to display information on the Local Acknowledgment feature. The no form of this command disables debugging output.
debug sdlc local-ackThis command has no arguments or keywords.
EXEC
You can select the frame types you want to monitor; the frame types correspond to bit flags. You can select 1, 2, 4, or 7, which is the decimal value of the bit flag settings. If you select 1, the octet is set to 00000001. If you select 2, the octet is set to 0000010. If you select 4, the octet is set to 00000100. If you want to select all frame types, select 7; the octet is 00000111. The default is 7 for all events. Table 1-47 defines these bit flags.
| Debug Command | Meaning |
|---|---|
| debug sdlc local-ack 1 | Only U-Frame events |
| debug sdlc local-ack 2 | Only I-Frame events |
| debug sdlc local-ack 4 | Only S-Frame events |
| debug sdlc local-ack 7 | All SDLC Local-Ack events (default setting) |
| Caution Because using this command is processor intensive, it is best to use it after hours, rather than in a production environment. It is also best to turn this command on by itself, rather than use it in conjunction with other debug commands. |
Figure 1-70 shows sample debug sdlc local-ack output.
Explanations for individual lines of output from Figure 1-70 follow.
The first line of output in the first group of lines shows the input to the SDLC Local Acknowledgment state machine:
SLACK (Serial3): Input = Network, LinkupRequest
Table 1-48 describes the fields in this line of output.
| Field | Description |
|---|---|
| SLACK | Indicates that the SDLC Local-Acknowledgment feature is providing the information. |
| (Serial3): | Interface type and unit number reporting the event. |
| Input = Network | Indicates that the source of the input. |
| LinkupRequest | Indicates the op code. A LinkupRequest is an example of possible values. |
The second line of output shows the change in the SDLC Local Acknowledgment state machine. In this case the AwaitSdlcOpen state is an internal state that has not changed while this display was captured.
SLACK (Serial3): Old State = AwaitSdlcOpen New State = AwaitSdlcOpen
The third line of output shows the output from the SDLC Local Acknowledgment state machine:
SLACK (Serial3): Input = Network, LinkupRequest
Use the debug sdllc EXEC command to display information about data link layer frames transferred between a device on a Token Ring and a device on a serial line via a router configured with the SDLLC feature. The no form of this command disables debugging output.
debug sdllcThis command has no arguments or keywords.
EXEC
The SDLLC feature translates between the SDLC link layer protocol used to communicate with devices on a serial line and the LLC2 link layer protocol used to communicate with devices on a Token Ring.
The router configured with the SDLLC feature must be attached to the serial line. The router sends and receives frames on behalf of the serial device on the attached serial line but acts as an SDLC station.
The topology between the router configured with the SDLLC feature and the Token Ring is network dependent and is not limited by the SDLLC feature.
Figure 1-71 shows sample debug sdllc output between link layer peers from the perspective of the SDLLC-configured router.
Explanations for individual fields of output from debug sdllc follow in Table 1-49:
| Field | Description |
|---|---|
| rx | Router receives message from the FEP. |
| explr rsp | Response to an explorer (TEST) frame previously sent by the router to FEP. |
| da | Destination address. This is the address of the router receiving the response. |
| sa | Source address. This is the address of the FEP sending the response to the router. |
| rif | Routing information field. |
| tx | Router sent message to the FEP. |
| short xid | Router sent the null XID to the FEP. |
| dsap | Destination service access point |
| ssap | Source service access point. |
| tx long xid | Router sent the XID type 2 to the FEP. |
| Rcvd | Router received layer 2 message from the FEP |
| SABME/LINKUP_REQ | Set asynchronous Balanced Mode Extended command. |
The following line of output indicates that an explorer frame response has been received by the router at address 4000.2000.1001 from the FEP at address C000.1020.1000 with the specified RIF. The original explorer sent to the FEP from the router is not monitored as part of the debug sdllc command.
SDLLC: rx explorer rsp, da 4000.2000.1001, sa C000.1020.1000, rif
8840.0011.00A1.0050
The following line of output indicates that the router sent the null XID (Type 0) to the FEP. The debugging information does not include the response to the XID message sent by the FEP to the router.
SDLLC: tx short xid, sa 4000.2000.1001, da C000.1020.1000, rif
88C0.0011.00A1.0050, dsap 4 ssap 4
The following line of output indicates that the router sent the XID command (Format 0 Type 2) to the FEP:
SDLLC: tx long xid, sa 4000.2000.1001, da C000.1020.1000, rif
88C0.0011.00A1.0050, dsap 4 ssap 4
The following line of output is the SABME response to the XID command previously sent by the router to the FEP:
Rcvd SABME/LINKUP_REQ pak from TR host
Use the debug serial interface EXEC command to display information on a serial connection failure. The no form of this command disables debugging output.
debug serial interfaceThis command has no arguments or keywords.
EXEC
If the show interface serial command shows that the line and protocol are down, you can use the debug serial interface command to isolate a timing problem as the cause of a connection failure. If the keepalive values in the mineseq, yourseen, and myseen fields are not incrementing in each subsequent line of output, there is a timing or line problem at one of end of the connection.
The output of the debug serial interface command can vary, depending on the type of WAN configured for an interface: DDR, Frame Relay, HDLC, HSSI, SMDS, or X.25. The output also can vary depending on the type of encapsulation configured for that interface. The hardware platform also can impact debug serial interface output.
The following sections show example debug serial interface displays for various configurations and describe the possible output the command can generate for these configurations.
Table 1-50 describes the error messages that the debug serial interface command can generate for a serial interface being used as a V.25bis dialer for dial-on-demand routing.
| 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 xxxxxxxx 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 xxxxxxxx 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. |
The following message is displayed if the encapsulation for the interface is Frame Relay (or HDLC) and the router attempts to send a packet containing an unknown packet type.
Illegal serial link type code xxx
Figure 1-72 shows sample debug serial interface output for an HDLC connection when keepalives have been enabled.
In Figure 1-72, the debug serial interface display shows that the remote router is not receiving all of the keepalives the router is sending. When the difference in the values in the myseq and mineseen fields exceeds three, the line goes down and the interface is reset.
Table 1-51 describes significant fields shown in Figure 1-72.
Table 1-52 describes additional error messages that the debug serial interface command can generate for HDLC.
| Field | Description |
|---|---|
| Illegal serial link type code xxx, PC = 0xnnnnnn | This message is displayed if the router attempts to send a packet containing an unknown packet type. |
| Illegal HDLC serial type code xxx, PC = 0xnnnnn | This message is displayed if an unknown packet type is received. |
| Serial 0: attempting to restart | This message is displayed periodically if the interface is down. The hardware is then reset to hopefully correct the problem. |
| Serial 0: Received bridge packet sent to nnnnnnnnn | This message is displayed if a bridge packet is received over a serial interface configured for HDLC, and bridging is not configured on that interface. |
On an HSSI interface, the debug serial interface command can generate the following additional error message:
HSSI0: Reset from 0xnnnnnnn
This message indicates that the HSSI hardware has been reset. The 0xnnnnnnn variable is the address of the routine requesting that the hardware be reset; this value is useful only to development engineers.
Table 1-53 describes error messages that the debug serial interface command can generate for ISDN Basic Rate.
| Message | Description |
|---|---|
| BRI: D-chan collision | Indicates that a collision on the ISDN D channel has occurred; the software will reattempt transmission. |
| Received SID Loss of Frame Alignment int. | Indicates that the ISDN hardware has lost frame alignment. This usually indicates a problem with the ISDN network. |
| Unexpected IMP int: ipr = 0xnn | Indicates that the ISDN hardware received an unexpected interrupt. The 0xnn variable indicates the value returned by the interrupt register. |
| BRI(d): RX Frame Length Violation. Length = n
BRI(d): RX Nonoctet Aligned Frame BRI(d): RX Abort Sequence BRI(d): RX CRC Error BRI(d): RX Overrun Error BRI(d): RX Carrier Detect Lost | Any of these messages may be displayed when a receive error occurs on one of the ISDN channels. The (d) indicates which channel it is on. These messages may indicate a problem with the ISDN network connection. |
| BRI0: Reset from 0xnnnnnnn | Indicates that the BRI hardware has been reset. The 0xnnnnnnn variable is the address of the routine that requested that the hardware be reset; it is useful only to development engineers. |
| BRI(d): Bad state in SCMs scm1 = x scm2 = x scm3 = x
BRI(d): Bad state in SCONs scon1 = x scon2 = x scon3 = x BRI(d): Bad state ub SCR; SCR = x | Any of these messages may be displayed if the ISDN hardware is not in the proper state. The hardware is then reset. If the message is displayed constantly, it usually indicates a hardware problem. |
| BRI(d): Illegal packet encapsulation = n | This message is displayed if a packet is received, but the encapsulation used for the packet is not recognized. It can indicate that the interface is misconfigured. |
Table 1-54 describes the additional error messages that the debug serial interface command can generate for an MK5025 device.
Figure 1-73 lists all of the messages that the debug serial interface command can generate when the encapsulation is set to PPP and PPP is negotiating configuration options.
A knowledge of the PPP protocol is necessary to understand the significance of the messages listed in Figure 1-73.
Figure 1-74 lists the debug serial interface messages that can be displayed when CHAP is enabled on a PPP interface.
The messages listed in Figure 1-74 indicate the current state of CHAP negotiation.
When encapsulation is set to SMDS, debug serial interface displays SMDS packets that have been sent and received, as well as any error messages resulting from SMDS packet transmission.
The error messages that the debug serial interface command can generate for SMDS follow.
The following message indicates that a new protocol requested SMDS to encapsulate the data for transmission. SMDS does not know yet how to encapsulate the protocol.
SMDS: Error on Serial 0, encapsulation bad protocol = x
The following message indicates that SMDS was asked to encapsulate a packet, but no corresponding destination E.164 SMDS address was found in any of the static SMDS tables or in the ARP tables:
SMDS send: Error in encapsulation, no hardware address, type = x
The following message indicates that a protocol such as CLNS or IP has been enabled on an SMDS interface, but the corresponding multicast addresses have not been configured. The n variable displays the link type for which encapsulation was requested. This value is only significant to Cisco as an internal protocol type value.
SMDS: Send, Error in encapsulation, type=n
The following messages can occur when a packet that was somehow corrupted is received on an SMDS interface. The router expected x, but received y.
SMDS: Invalid packet, Reserved NOT ZERO, x y
SMDS: Invalid packet, TAG mismatch x y
SMDS: Invalid packet, Bad TRAILER length x y
The following messages can indicate an invalid length for an SMDS packet:
SMDS: Invalid packet, Bad BA length x
SMDS: Invalid packet, Bad header extension length x
SMDS: Invalid packet, Bad header extension type x
SMDS: Invalid packet, Bad header extension value x
The following messages are displayed when the debug serial interface command is enabled:
Interface Serial 0 Sending SMDS L3 packet:
SMDS: dgsize:x type:0xn src:y dst:z
If the debug serial interface command is enabled, the following message can be displayed when a packet is received on an SMDS interface, but the destination SMDS address does not match any on that interface:
SMDS: Packet n, not addressed to us
Use the debug serial packet EXEC command to display more detailed serial interface debugging information than you can obtain using debug serial interface command. The no form of this command disables debugging output.
debug serial packetThis command has no arguments or keywords.
EXEC
The debug serial packet command generates output that is dependent on the type of serial interface and the encapsulation that is running on that interface. The hardware platform also can impact debug serial packet output.
Currently, the debug serial packet command displays output for only DDR, PPP, and SMDS encapsulations.
When you enable the debug serial packet command and DDR is enabled on the interface, information concerning the cause of any calls (called Dialing cause) may be displayed.
The following line of output for an IP packet lists the name of the DDR interface and the source and destination addresses of the packet.
Dialing cause: Serial0: ip (s=131.108.1.111 d=131.108.2.22)
The following line of output for a bridged packet lists the DDR interface and the type of packet (in hexadecimal). For information on these packet types, see Appendix B, "Ethernet Type Codes," of the Router Products Command Reference publication.
Dialing cause: Serial1: Bridge (0x6005)
Figure 1-75 shows sample debug serial packet output when PPP is enabled on the interface.
The preceding five messages may appear when PPP is attempting to negotiate a link. They indicate that PPP received an ACK for option type, and if the option has a value, the value that was acked also is displayed. This is possibly useful in debugging PPP link establishment, but is mostly useful with some knowledge of the PPP protocol.
Table 1-55 describes significant fields shown in Figure 1-75.
| Field | Description |
|---|---|
| ppp: config ACK received | The router has received an acknowledgment packet in response to the configuration negotiation request packet it sent. |
| type = nnn | Number indicating the LCP configuration option to be negotiated. Possible values include:
1--Maximum Received Unit (MRU) 2--Async Control Character Map 3--Authentication Protocol 4--Quality Protocol 5--Magic Number 6--Undefined 7--Protocol Field Compression 8--Address and Control Field Compression 9--32 Bit FCS |
| value = yyy | Value of the LCP configuration option that has been negotiated. |
Additional messages that the debug serial packet command can generate when PPP is enabled follow.
The following message is displayed when PPP sends a packet onto the line. The "Serial0" shows the interface the packet is sent on. The state corresponds to a PPP state machine state, and is only useful to technical support staff. The link can be either ppp-lcp or ppp-ipcp, indicating that it is either a PPP LCP packet or a PPP IPCP packet. The code is the PPP packet type being transmitted, the ID is a sequence number for this packet, and LEN is the length of packet. This message is only displayed for PPP-generated packets, not for all packets using PPP encapsulation.
PPP send: on Serial0 STATE= 4 LINK= ppp-lcp, CODE= 5, ID= 345, LEN = 9
The following message is displayed if the PPP timer expires. It indicates that the remote side did not respond to the packet in the time allowed.
ppp: TIMEout: Time= 3245532 State= 4
The following three messages may be displayed if PPP receives a packet that is incorrectly formatted:
ppp: rcvd short header for ppp-lcp
ppp: rcvd illegal length for ppp-lcp
ppp: rcvd short packet. len x > y for ppp-lcp
The following message is displayed when a PPP-specific packet is received. It either will be for ppp-lcp or ppp-ipcp, depending on which PPP layer the packet is for. It will give a state, which is a state in the PPP state machine; a code, which is the type of PPP packet received; the ID, which is a sequence number; and the length of the packet.
PPP input(ppp-lcp): state = 4 code = 5 id = 345 len = 9
The following message is displayed if PPP has received an ACK for a configuration request it transmitted. The ID can be matched with an ID displayed in the PPP send debug message to verify which packet was acked.
ppp: state = 4 fsm_rconfack(ppp-lcp): rcvd id 345
One of the following messages is displayed when PPP receives a configuration packet from the other side. It displays the configuration type and whether there is a value for that type, the value, and whether it is going to ack, nack, or reject this configuration option.
ppp: received config for type = x value = y acked
ppp: received config for type = x value = y rejected
ppp: received config for type = x value = y nacked
Figure 1-76 shows sample output when SMDS is enabled on the interface.
As Figure 1-76 shows, when encapsulation is set to SMDS, debug serial packet displays the entire SMDS header (in hex), as well as some payload data on transmit or receive. This information is useful only when you have an understanding of the SMDS protocol. The first line of the output indicates either Sending or Receiving.
Use the debug source-bridge EXEC command to display information about packets and frames transferred across a source route bridge. The no form of this command disables debugging output.
debug source-bridgeThis command has no arguments or keywords.
EXEC
Figure 1-77 shows sample debug source-bridge output for peer bridges using TCP as a transport mechanism. The RSRB network configuration has ring 2 and ring 1 bridged together through remote peer bridges. The remote peer bridges are connected via a serial line and use TCP as the transport mechanism.
The following line of output indicates that a remote explorer frame has been sent to IP address 131.108.250.1 and like all RSRB TCP connections, has been assigned port 1996. The bridge belongs to ring group 5. The explorer frame originated from ring number 2. The routing information field (RIF) descriptor has been generated by the local station and indicates that the frame was sent out via bridge 1 onto virtual ring 5.
RSRB: remote explorer to 5/131.108.250.1/1996 srn 2 [C840.0021.0050.0000]
The following line of output indicates that a request for remote peer information has been sent to IP address 131.108.250.1, TCP port 1996. The bridge belongs to ring group 5.
RSRB: Version/Ring XReq sent to peer 5/131.108.250.1/1996
The following line of output is the response to the version request previously sent. The response is sent from IP address 131.108.250.1, TCP port 1996. The bridge belongs to ring group 5.
RSRB: Received version reply from 5/131.108.250.1/1996 (version 2)
The following line of output is the response to the ring request previously sent. The response is sent from IP address 131.108.250.1, TCP port 1996. The target ring number is 2, virtual ring number is 5, the offset is 18, and the length of the frame is 10 bytes.
RSRB: DATA: 5/131.108.250.1/1996 Ring Xchg Rep, trn 2, vrn 5, off 0, len 10
The following line of output indicates that bridge 1 and ring 1 have been added to the source-bridge table for IP address 131.108.250.1, TCP port 1996.
RSRB: added bridge 1, ring 1 for 5/131.108.250.1/1996
The following line of output indicates that a packet containing an explorer frame has come across virtual ring 5 from IP address 131.108.250.1, TCP port 1996. The packet is 69 bytes in length. This packet is received after the Ring Exchange information was received and updated on both sides.
RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69
The following line of output indicates that a packet containing data has come across virtual ring 5 from IP address 131.108.250.1 over TCP port 1996. The packet is being placed on the local target ring 2.The packet is 92 bytes in length.
RSRB: DATA: 5/131.108.250.1/1996 Forward trn 2, vrn 5, off 0, len 92
The following line of output indicates that a packet containing data is being forwarded to the peer that has IP 131.108.250.1 address belonging to local ring 2 and bridge 1. The packet is forwarded via virtual ring 5. This packet is sent after the Ring Exchange information was received and updated on both sides.
RSRB: DATA: forward Forward srn 2, br 1, vrn 5 to peer 5/131.108.250.1/1996
Figure 1-78 shows sample debug source-bridge output for peer bridges using direct encapsulation as a transport mechanism. The RSRB network configuration has ring 1 and ring 2 bridged together through peer bridges. The peer bridges are connected via a serial line and use TCP as the transport mechanism.
The following line of output indicates that a remote explorer frame has been sent to remote peer Serial1, which belongs to ring group 5. The explorer frame originated from ring number 1. The routing information field (RIF) descriptor 0011.0050 has been generated by the local station and indicates that the frame was sent out via bridge 1 onto virtual ring 5.
RSRB: remote explorer to 5/Serial1 srn 1 [C840.0011.0050.0000]
The following line of output indicates that a request for remote peer information has been sent to Serial1. The bridge belongs to ring group 5.
RSRB: Version/Ring XReq sent to peer 5/Serial1
The following line of output is the response to the version request previously sent. The response is sent from Serial 1. The bridge belongs to ring group 5 and the version is 2.
RSRB: Received version reply from 5/Serial1 (version 2)
The following line of output is the response to the ring request previously sent. The response is sent from Serial1. The target ring number is 2, virtual ring number is 5, the offset is 0, and the length of the frame is 39 bytes.
RSRB: IFin: 5/Serial1 Ring Xchg Rep, trn 2, vrn 5, off 0, len 39
The following line of output indicates that bridge 1 and ring 1 have been added to the source-bridge table for Serial1.
RSRB: added bridge 1, ring 1 for 5/Serial1
Use the debug source event EXEC command to display information on source-route bridging activity. The no form of this command disables debugging output.
debug source eventThis command has no arguments or keywords.
EXEC
Output of the debug source bridge command is identical to the output of this command.
Figure 1-79 shows sample debug source event output.
Table 1-56 describes significant fields shown in Figure 1-79.
Examples of other debug source event messages that can be displayed follow.
In the following example messages, SRBn or RSRBn denotes a message associated with interface Token Ring n. An n of 99 denotes the remote side of the network.
SRBn: no path, s: <src MAC addr>d: <dst MAC addr>rif: <rif>
In the preceding example, a bridgeable packet came in on interface Token Ring n but there was nowhere to send it. This is most likely a configuration error. For example, an interface has source bridging turned on, but it is not connected to another source bridging interface or a ring group.
In the following example, a bridgeable packet has been forwarded from Token Ring n to the target ring. The two interfaces are directly linked.
SRBn: direct forward (srn <ring>bn <bridge>trn <ring>)
In the following examples, a proxy explorer reply was not generated because there was no way to get to the address from this interface. The packet came from the node with the first <address>.
SRBn: br dropped proxy XID, <address> for <address>, wrong vring (rem)
SRBn: br dropped proxy TEST, <address> for <address>, wrong vring (rem)
SRBn: br dropped proxy XID, <address> for <address>, wrong vring (local)
SRBn: br dropped proxy TEST, <address> for <address>, wrong vring (local)
SRBn: br dropped proxy XID, <address> for <address>, no path
SRBn: br dropped proxy TEST, <address> for <address>, no path
In the following example, an appropriate proxy explorer reply was generated on behalf of the second <address>. It is sent to the first <address>.
SRBn: br sent proxy XID, <address> for <address>[<rif>]
SRBn: br sent proxy TEST, <address> for <address>[<rif>]
The following example indicates that the broadcast bits were not set, or that the routing information indicator on the packet was not set:
SRB<unit#>: illegal explorer, s: <srcMACaddr> d: <destMACaddr> rif:
<RIFstring>
The following example indicates that the direction bit in the RIF field was set, or that an odd packet length was encountered. Such packets are dropped.
SRB<unit #>: bad explorer control, D set or odd
The following example indicates that a spanning explorer was dropped because the spanning option was not configured on the interface:
SRB<unit #>: span dropped, input off, s: <src mac addr> d: <dest mac addr>
rif: <rif string>
The following example indicates that a spanning explorer was dropped because it had traversed the ring previously:
SRB<unit #>: span violation, s: <src mac addr> d: <dest mac addr> rif:
<rif string>
The following example indicates that an explorer was dropped because the maximum hop count limit was reached on that interface:
SRB<unit #>: max hops reached - <hop cnt>, s: <src mac addr> d: <dest mac addr>
rif: <rif string>
The following example indicates that the ring exchange request was sent to the indicated peer. This request tells the remote side which rings this node has and asks for a reply indicating which rings that side has.
RSRB: sent RingXreq to <ring group>/<ip addr>
The following example indicates that a message has been sent to the remote peer. The <label> variable can be AHDR (active header), PHDR (passive header), HDR (normal header), or DATA (data exchange), and <op> can be Forward, Explorer, Ring Xchg, Req, Ring Xchg, Rep, Unknown Ring Group, Unknown Peer, or Unknown Target Ring.
RSRB: <label>: sent <op> to <ring group>/<ip addr>
The following example indicates that the remote bridge and ring pair have been removed from or added to the local ring group table because the remote peer has changed:
RSRB: removing bn <bridge> rn <ring> from <ring group>/<ip addr>
RSRB: added bridge <bridge>, ring <ring> for <ring group>/<ip addr>
The following example shows miscellaneous remote peer connection establishment messages:
RSRB: peer <ring group>/<ip addr> closed [last state n]
RSRB: passive open <ip addr>(remote port) -> <local port>
RSRB: CONN: opening peer <ring group>/<ip addr>, attempt n
RSRB: CONN: Remote closed <ring group>/<ip addr> on open
RSRB: CONN: peer <ring group>/<ip addr> open failed, <reason>[code]
The following example shows that an explorer packet was propagated onto the local ring from the remote ring group:
RSRBn: sent local explorer, bridge <bridge> trn <ring>, [rif]
The following messages indicate that the remote source-route bridging code found the packet to be in error:
RSRBn: ring group <ring group> not found
RSRBn: explorer rif [rif] not long enough
The following example indicates that a buffer could not be obtained for a ring exchange packet; this is an internal error.
RSRB: couldn't get pak for ringXchg
The following example indicates that a ring exchange packet was received that had an incorrect length; this is an internal error.
RSRB: XCHG: req/reply badly formed, length <pak length>, peer <peer id>
The following example indicates that a ring entry was removed for the peer; the ring was possibly disconnected from the network, causing the remote router to send an update to all its peers.
RSRB: removing bridge <br #> ring <ring #> from <peer name> <ring type>
The following example indicates that a ring entry was added for the specified peer; the ring was possibly added to the network, causing the other router to send an update to all its peers.
RSRB: added bridge <br #>, ring <ring #> for <peer id>
The following example indicates that no memory was available to add a ring number to the ring group specified; this is an internal error.
RSRB: no memory for ring element <ring group #>
The following example indicates that memory was corrupted for a connection block; this is an internal error.
RSRB: CONN: corrupt connection block
The following example indicates that a connector process started, but that there was no packet to process; this is an internal error.
RSRB: CONN: warning, no initial packet, peer: <ip addr> <peer pointer>
The following example indicates that a packet was received with a version number different from the one present on the router:
RSRB: IF New version. local=<local version #>, remote=<remote version>,
<pak op code> <peer id>
The following example indicates that a packet with a bad op code was received for a direct encapsulation peer; this is an internal error.
RSRB: IFin: bad op <op code> (op code string) from <peer id>
The following example indicates that the virtual ring header will not fit on the packet to be sent to the peer; this is an internal error:
RSRB: vrif_sender, hdr won't fit
The following example indicates that the specified peer is being opened. The retry count specifies the number of times the opening operation is attempted.
RSRB: CONN: opening peer <peer id> <retry count>
The following example indicates that the router, configured for FST encapsulation, received a version reply to the version request packet it had sent previously:
RSRB: FST Rcvd version reply from <peer id> (version #)
The following example indicates that the router, configured for FST encapsulation, sent a version request packet to the specified peer:
RSRB: FST Version Request. op = <opcode>, <peer id>
The following example indicates that the router received a packet with a bad op code from the specified peer; this is an internal error.
RSRB: FSTin: bad op <opcode> (op code string) from <peer id>
The following example indicates that the TCP connection between the router and the specified peer is being aborted:
RSRB: aborting <ring group #>/<peer id> (vrtcpd_abort called)
The following example indicates that an attempt to establish a TCP connection to a remote peer timed out:
RSRB: CONN: attempt timed out
The following example indicates that a packet was dropped because the ring group number in the packet did not correlate with the ring groups configured on the router:
RSRB<unit #>: ring group <ring group #> not found
Use the debug span EXEC command to display information on changes in the spanning-tree topology when debugging a transparent bridge. The no form of this command disables debugging output.
debug spanThis command has no arguments or keywords.
EXEC
This command is useful for tracking and verifying that the spanning-tree protocol is operating correctly.
Sample debug span output for an IEEE BPDU packet follows:
ST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00
Figure 1-80 shows the preceding debug span output broken up by fields and labeled to aid documentation.
Table 1-57 describes significant fields shown in this debug span output.
| Field | Description |
|---|---|
| ST: | Indicates that this is a spanning tree packet |
| Ether4 | Interface receiving the packet |
| (A) 0000 | Indicates that this is an IEEE BPDU packet |
| (B) 00 | Version |
| (C) 00 | Command Mode
00 indicates config BPDU |
| (D) 00 | Topology change acknowledgment
00 indicates no change 80 indicates a change notification |
| (E) 000A | Root priority |
| (F) 080002A02D67 | Root ID |
| (G) 00000000 | Root path cost (0 means the sender of this BPDU packet is the root bridge) |
| (H) 000A | Bridge priority |
| (I) 080002A02D67 | Bridge ID |
| (J) 80 | Port priority |
| (K) 01 | Port No. 1 |
| (L) 0000 | Message age in 256ths of a second (0 seconds, in this case) |
| (M) 1400 | Maximum age in 256ths of a second (20 seconds, in this case) |
| (N) 0200 | Hello time in 256ths of a second (2 seconds, in this case) |
| (O) 0F00 | Forward delay in 256ths of a second (15 seconds, in this case) |
Sample debug span output for a DEC BPDU packet follows:
ST: Ethernet4 E1190100000200000C01A2C90064008000000C0106CE0A01050F1E6A
Figure 1-81 shows the preceding debug span output broken up by fields and labeled to aid documentation.
Table 1-58 describes significant fields shown in this debug span output.
Use the debug stun packet EXEC command to display information on packets traveling through the STUN links. Use the no form of this command to disable debugging output.
debug stun packet [group] [address]
no debug stun packet [group] [address]
| group | (Optional.) Decimal integer assigned to a group. Using this option limits output to packets associated with the specified STUN group. |
| address | (Optional.) Output is further limited to only those packets containing the specified STUN address. The address argument is in the appropriate format for the STUN protocol running for the specified group. |
EXEC
Because using this command is processor intensive, it is best to use it after hours, rather than in a production environment. It is also best to turn this command on by itself, rather than use it in conjunction with other debug commands.
Figure 1-82 shows sample debug stun packet output.
Explanations for individual lines of output from Figure 1-82 follow.
The following line of output describes an X1 type of packet.
STUN sdlc: 0:00:04 Serial3 NDI: (0C2/008) U: SNRM PF:1
Table 1-59 describes significant fields shown in this line of debug stun packet output.
| Field | Description |
|---|---|
| STUN sdlc: | Indicates that the STUN feature is providing the information. |
| 0:00:04 | Time elapsed since receipt of previous packet. |
| Serial3 | Interface type and unit number reporting the event. |
| NDI: | Indicates the type of cloud separating the SDLC end nodes. Possible values follow:
NDI--Network input SDI--Serial link |
| 0C2 | SDLC address of the SDLC connection. |
| 008 | Indicates a modulo value of 8. |
| U:SNRM | Indicates the frame type followed by the command or response type. In this case it is an Unnumbered frame that contains an SNRM (Set Normal Response Mode) command. The possible frame types are as follows:
I--Information frame S--Supervisory frame. The possible commands and responses are: RR (Receive Ready), RNR (Receive Not Ready), and REJ (Reject). U--Unnumbered frame. The possible commands are: UI (Unnumbered Information), SNRM, DISC/RD (Disconnect/Request Disconnect), SIM/RIM, XID Exchange Identification), TEST. The possible responses are UA (unnumbered acknowledgment), DM (Disconnected Mode), and FRMR (Frame Reject Mode) |
| PF:1 | Poll/Final bit.
0--Off 1--On |
The following line of output describes an X2 type of packet:
STUN sdlc: 0:00:00 Serial3 SDI: (0C2/008) S: RR PF:1 NR:000
All of the fields in the previous line of output match those for an X1 type of packet, except the last field, which is additional. NR:000 indicates a receive count of 0; the range for the receive count is 0 to 7.
The following line of output describes an X3 type of packet:
STUN sdlc: 0:00:00 Serial3 SDI: (0C2/008) S:I PF:1 NR:000 NS:000
All of the fields in the previous line of output match those for an X2 type of packet, except the last field, which is additional. NS:000 indicates a send count of 0; the range for the send count is 0 to 7.
Use the debug tftp EXEC command to display TFTP debugging information when encountering problems netbooting or using the configure network or write network commands. The no form of this command disables debugging output.
debug tftpThis command has no arguments or keywords.
EXEC
Figure 1-83 shows sample debug tftp output from the EXEC command write network.
Table 1-60 describes significant fields shown in the first line of output from Figure 1-83.
| Message | Description |
|---|---|
| TFTP: | Indicates that this entry describes a TFTP packet. |
| msclock 0x292B4; | Internal timekeeping clock (in milliseconds). |
| Sending write request (retry 0) | Indicates the TFTP operation. |
| socket_id 0x301DA8 | Unique memory address for the socket for the TFTP connection. |
Use the debug token ring EXEC command to display messages about Token Ring interface activity. The no form of this command disables debugging output.
debug token ringThis command has no arguments or keywords.
EXEC
This command reports several lines of information for each packet sent or received and is intended for low traffic, detailed debugging.
The Token Ring interface records provide information regarding the current state of the ring. These messages are only displayed when the debug token events command is enabled.
The debug token ring command invokes verbose Token Ring hardware debugging. This includes detailed displays as traffic arrives and departs the unit.
Figure 1-84 shows sample debug token ring output.
Descriptions of sample lines of output in Figure 1-84 follow.
Table 1-61 describes significant fields shown in the second line of output from Figure 1-84.
TR0: in: MAC: acfc: 0x1105 Dst: c000.ffff.ffff Src: 5000.1234.5678 bf: 0x45
| Message | Description |
|---|---|
| TR0: | Name of the interface associated with the Token Ring event. |
| in: | Indicates whether the packet was input to the interface (in) or output from the interface (out). |
| MAC: | Indicates the type of packet, as follows:
MAC--Media Access Control LLC--Link Level Control |
| acfc: 0x1105 | Access Control, Frame Control bytes, as defined by the IEEE 802.5 standard. |
| Dst: c000.ffff.ffff | Destination address of the frame. |
| Src: 5000.1234.5678 | Source address of the frame. |
| bf: 0x45 | Bridge flags for internal use by technical support staff. |
Table 1-62 describes significant fields shown in the third line of output from Figure 1-84.
TR0: in: riflen 0, rd_offset 0, llc_offset 40
| Message | Description |
|---|---|
| TR0: | Name of the interface associated with the Token Ring event. |
| in: | Indicates whether the packet was input to the interface (in) or output from the interface (out). |
| riflen 0 | Length of the RIF field (in bytes). |
| rd_offset 0 | Offset (in bytes) of the frame pointing to the start of the RIF field. |
| llc_offset 40 | Offset in the frame pointing to the start of the LLC field. |
Table 1-63 describes significant fields shown in the fifth line of output from Figure 1-84.
TR0: out: LLC: AAAA0300 00009000 00000100 AAC00000 00000802 50001234 ln: 28
| Message | Description |
|---|---|
| TR0: | Name of the interface associated with the Token Ring event. |
| out: | Indicates whether the packet was input to the interface (in) or output from the interface (out). |
| LLC: | Indicates the type of frame, as follows:
MAC--Media Access Control LLC--Link Level Control |
| AAAA0300.... | This and the octets that follow it indicate the contents (hex) of the frame. |
| ln: 28 | Indicates the length of the information field (in bytes). |
Use the debug vines arp EXEC command to display debugging information on all ARP packets that the router sends or receives. The no form of this command disables debugging output.
debug vines arpThis command has no arguments or keywords.
EXEC
Figure 1-85 shows sample debug vines arp output.
In Figure 1-85, the first line shows that the router received an ARP request (type 0) from station address 0260.8c43.a7e4. The second line shows that the router is sending back the ARP service response (type 1) indicating that it is willing to assign VINES Internet addresses. The third line shows that the router received a VINES Internet address assignment request (type 2) from address 0260.8c43.a7e4. The fourth line shows that the router is responding (type 3) to the address assignment request from the client and assigning it the address 3001153C:8004.
Table 1-64 describes significant fields shown in Figure 1-85.
Use the debug vines echo EXEC command to display information on all MAC-level echo packets that the router sends or receives. Banyan VINES interface testing programs make use of these echo packets. The no form of this command disables debugging output.
debug vines echoThis command has no arguments or keywords.
EXEC
Figure 1-86 shows sample debug vines echo output.
Table 1-65 describes the fields shown in Figure 1-86.
| Field | Description |
|---|---|
VINESECHO
| Indicates that this is a debug vines echo message. |
| 100 byte packet | Packet size in bytes. |
| from 0260.8c43.a7e4 | Source address of the echo packet. |
Use the debug vines ipc EXEC command to display information on all transactions that occur at the VINES IPC layer, which is one of the two VINES transport layers. The no form of this command disables debugging output.
debug vines ipcThis command has no arguments or keywords.
EXEC
You can use the debug vines ipc command to discover why an IPC layer process on the router is not communicating with another IPC layer process on another router or Banyan VINES server.
Figure 1-87 shows sample debug vines ipc output for three pairs of transactions. For more information about these fields or their values, refer to Banyan VINES documentation.
Table 1-66 describes the fields shown in Figure 1-87. For more information about these fields or their values, refer to Banyan VINES documentation.
Use the debug vines netrpc EXEC command to display information on all transactions that occur at the VINES NetRPC layer, which is the VINES Session/Presentation layer. The no form of this command disables debugging output.
debug vines netrpcThis command has no arguments or keywords.
EXEC
You can use the debug vines netrpc command to discover why a NetRPC layer process on the router is not communicating with another NetRPC layer process on another router or Banyan server.
Figure 1-88 shows sample debug vines netrpc output. For more information about these fields or their values, refer to Banyan VINES documentation.
Table 1-67 describes the fields shown in the first line of output in Figure 1-88. For more information about these fields or their values, refer to Banyan VINES documentation.
Use the debug vines packet EXEC command to display general VINES debugging information. This information includes packets received, generated, and forwarded, as well as failed access checks and other operations. The no form of this command disables debugging output.
debug vines packetThis command has no arguments or keywords.
EXEC
Figure 1-89 shows sample debug vines packet output.
The following information describes selected lines of output from Figure 1-89.
Table 1-68 describes the fields shown in the first line of output.
| Field | Description |
|---|---|
VINES:
| Indicates that this is a Banyan VINES packet. |
| s = 30028CF9:1 | Source address of the packet. |
| (Ether2) | Indicates the interface through which the packet was received. |
| d = FFFFFFFF:FFFF | Indicates that the destination is a broadcast address. |
| rcvd w/ hops 0 | Indicates that the packet was received because it was a local broadcast packet. The remaining hop count in the packet was zero (0). |
In the second line of output that follows, the destination is the address 3002ABEA:1 associated with interface Ether2. Source address 3000CBD4:1 sent a packet to this destination through the gateway at address 3000ABEA:1.
VINES: s=3000CBD4:1 (Ether1), d=3002ABEA:1 (Ethernet2), g=3002ABEA:1, sent
In the third line of output that follows, the router being debugged is the destination address (3000B959:1).
VINES: s=3000CBD4:1 (Ether1), d=3000B959:1, rcvd by gw
In the following fifth line of output, (local) indicates that the router being debugged generated the packet.
VINES: s=3000B959:1 (local), d=3000CBD4:1 (Ether1), g=3000CBD4:1, sent
Use the debug vines routing EXEC command to display information on all RTP update messages sent or received and all routing table activities that occur in the router. The no form of this command disables debugging output.
debug vines routingThis command has no arguments or keywords.
EXEC
Figure 1-90 shows sample debug vines routing output.
Figure 1-90 describes two VINES routing updates; the first includes two entries and the second includes three entries. The following describes selected lines of output from Figure 1-90.
The following first line shows that the router sent a periodic routing update to the broadcast address FFFFFFFF:FFFF through the Ethernet3 interface.
VINESRTP: sending update to FFFFFFFF:FFFF on Ethernet3
The following second line indicates that the router knows how to reach network 3000073B, which is a metric of 2 away from the router. The value that follows the metric (0.4 seconds) interprets the metric in seconds.
network 3000073B, metric 2 (0.4 seconds)
The following third line indicates that the router knows how to reach network 27AF9A, which is a metric of 2 away from the router. The value that follows the metric (0.4 seconds) interprets the metric in seconds.
network 27AF9A, metric 2 (0.4 seconds)
The following fourth line of output indicates that the router received a routing update from the VINES server at VINES address 27AF9A:1 through the Ethernet2 interface.
VINESRTP: received update from 27AF9A:1 on Ethernet2
The following fifth line of output implies that the server sending this update is directly accessible to the router (even though VINES servers do not explicitly list themselves in routing updates). Because this is an implicit entry in the table, there is no metric associated with this line of output.
network 27AF9A from the server
As the first actual entry in the routing update from the VINES server at 27AF9A:1, the following sixth line indicates that network 30019AC7 can be reached by sending to this server. This network is a metric of 2 away from the sending server. The value that follows the metric (0.4 seconds) interprets the metric in seconds.
network 30019AC7, metric 2 (0.4 seconds)
Use the debug vines service EXEC command to display information on all transactions that occur at the VINES Service (or applications) layer. The no form of this command disables debugging output.
debug vines serviceThis command has no arguments or keywords.
EXEC
You can use the debug vines service command to discover why a VINES Service layer process on the router is not communicating with another Service layer process on another router or Banyan server.
Figure 1-91 shows sample debug vines service output.
As Figure 1-91 suggests, debug vines service lines of output appear as activity pairs--either a sent/response pair as shown, or as a received/sent pair.
Table 1-69 describes the fields shown in the second line of output in Figure 1-91. For more information about these fields or their values, refer to Banyan VINES documentation.
| Field | Description |
|---|---|
VSRV:
| Indicates that this is output from the debug vines service command. |
| Get Time Info | Indicates one of three packet types:
Get Time Info Time Set Time Sync |
| response from | Indicates whether the packet was sent to another router, a response from another router, or received from another router. |
| Townsaver | Indicates the machine name as assigned using the VINES host command, or IP address of the other router. |
| time: 01:47:54 PDT Apr 29 1993 | Indicates the current time in hours:minutes:seconds and current date. |
Table 1-70 describes the fields shown in the third line of output in Figure 1-91. This line is an extension of the first two lines of output. For more information about these fields or their values, refer to Banyan VINES documentation.
| Field | Description |
|---|---|
VSRV:
| Indicates that this is output from the debug vines service command. |
| epoch | Indicates that this line of output describes a VINES epoch. |
| SS@Aloe@Servers-10 | Epoch name. |
| age: 0:15:15 | Epoch--elapsed time since the time was last set in the network. |
Use the debug vines table EXEC command to display information on all modifications to the VINES routing table. The no form of this command disables debugging output.
debug vines tableThis command has no arguments or keywords.
EXEC
This command provides a subset of the information provided by the debug vines routing command, as well as some more detailed information on table additions and deletions.
Figure 1-92 shows sample debug vines table output.
Table 1-71 describes significant fields shown in Figure 1-92.
| Field | Description |
|---|---|
VINESRTP:
| Indicates that this is a debug vines routing or debug vines table message. |
| create neighbor 3001153C:8004 | Indicates that the client at address 3001153C:8004 has been added to the Banyan VINES neighbor table. |
interface Ethernet 0
| Indicates that this neighbor can be reached through the router interface named Ethernet0. |
Use the debug xns packet EXEC command to display information on XNS packet traffic, including the addresses for source, destination, and next hop router of each packet. The no form of this command disables debugging output.
debug xns packetThis command has no arguments or keywords.
EXEC
To gain the fullest understanding of XNS routing activity, you should enable debug xns routing and debug xns packet together.
Figure 1-93 shows sample debug xns packet output.
Table 1-72 describes significant fields shown in Figure 1-93.
| Field | Description |
|---|---|
XNS:
| Indicates that this is an XNS packet. |
| src = 5.0000.0c02.6d04 | Indicates that the source address for this message is 0000.0c02.6d04 on network 5. |
| dst = 5.ffff.ffff.ffff | Indicates that the destination address for this message is the broadcast address ffff.ffff.ffff on network 5. |
| packet sent | Indicates that the packet to destination address 5.ffff.ffff.ffff in Figure 1-93, as displayed using the debug xns packet command, was queued on the output interface. |
| rcvd. on Ethernet0 | Indicates that the router just received this packet through the Ethernet0 interface. |
local processing
| Indicates that the router has examined the packet and determined that it must process it, rather than forwarding it. |
Use the debug xns routing EXEC command to display information on XNS routing transactions. The no form of this command disables debugging output.
debug xns routingThis command has no arguments or keywords.
EXEC
To gain the fullest understanding of XNS routing activity, enable debug xns routing and debug xns packet together.
Figure 1-94 shows sample debug xns routing output.
Table 1-73 describes significant fields shown in Figure 1-94.
| Field | Description |
|---|---|
XNSRIP:
| Indicates that this is an XNS routing packet. |
| sending standard periodic update | The router indicates that this is a periodic XNS routing information update. |
| to 5.ffff.ffff.ffff | Indicates that the destination address is ffff.ffff.ffff on network 5. |
| via Ethernet2 | Name of the output interface. |
| network 1, hop count 1 | Indicates that network 1 is one hop away from this router. |
| got standard update from 1.0000.0c00.440f | The router indicates that it has received an XNS routing information update from address 0000.0c00.440f on network 1. |
| socket 1 | The socket number is a well-known port for XNS. Possible values include:
1--routing information 2--echo 3--router error |
Use the debug x25 all EXEC command to display information on all X.25 traffic, this includes data, control messages, and flow control (RR and RNR) packets. The no form of this command disables debugging output.
debug x25 allThis command has no arguments or keywords.
EXEC
This command is particularly useful for diagnosing problems encountered when placing CALLs.
The debug x25 all output includes data, control messages and flow control packets for all of the router's virtual circuits. The debug x25 events and debug x25 vc commands provide a subset of this output.
| Caution Because debug x25 all displays all X.25 traffic, it is processor intensive and can render the router useless. Only use debug x25 all when the aggregate of all X.25 traffic is fewer than five packets per second. |
Figure 1-95 shows sample debug x25 all output.
Figure 1-95 shows a typical exchange of packets between two X.25 devices on a network. The first line of output in Figure 1-95, shown below, describes a RESTART packet.
Serial2 (236414440): X25 O R3 RESTART (5) 8 lci 0 cause 7 diag 0
Table 1-74 describes the fields in this line of output.
Notice that the first DATA packet in Figure 1-95 contains two fields not yet documented.
Serial2 (236426444): X25 I P4 DATA (103) 8 lci 1024 PS 0 PR 0
Table 1-75 describes the PS and PR fields that can appear in a debug x25 all display.
| Field | Description |
|---|---|
PS 0
| Packet send sequence number; used for flow control of the outgoing packet stream. Present only in DATA packets. |
PR 0
| Packet receive sequence number; used for flow control of the incoming packet. stream. Present only in DATA, RR, and RNR packets. |
In Figure 1-95, notice also that the CALL REQUEST packet precedes three other lines of output that have a unique format.
Serial2 (236424436): X25 I P1 CALL REQUEST (11) 8 lci 1024
From(2): 49 To(2): 46
Facilities: (0)
First byte of call user data (4): 0xCC
These lines indicate that the CALL REQUEST packet has a two-digit source address, 49, and a two-digit destination address, 46. These are X.121 addresses that can be from 0 to 15 digits in length. The Facilities field is (0) bytes in length, indicating that no X.25 facilities are being requested. The optional call user data field is 4 bytes in length. The first of these bytes has the hexadecimal value of CC, indicating that the caller intends for IP datagrams to be carried on the VC.
The two lines of output in Figure 1-95 that begin with X25-Switch are shown below.
X25-Switch (274428): X25 O D1 PVC-SETUP, wait to connect (29) <Serial2 pvc 3><Serial2 pvc 1> 2/1 128/64
X25-Switch (274432): X25 I D1 PVC-SETUP, connected (29) <Serial2 pvc 3><Serial2 pvc 1> 2/1 128/64
These lines of output do not describe standard X.25 packets. Instead, they describe proprietary Cisco messages that represent a tunneled PVC setup between two routers. Table 1-76 describes the fields these two lines of output.
| Field | Description |
|---|---|
| X25-Switch | Indicates that this message travels over a TCP connection. |
| (274428) | System clock (in milliseconds). Useful for determining the amount of time between events. |
| X25 | Indicates that this message describes an X.25 event. |
O
| Indicates whether the X.25 message was input (I) or output (O) through the interface. |
D1
| State of the permanent virtual circuit. Possible values follow.
D1--Flow control ready D2--DTE reset request D3--DCE reset indication See Annex B of the 1984 CCITT X.25 Recommendation for more information on these states. |
| waiting to connect | State of the PVC. Some of these strings only apply to PVCs that are remotely tunneled over a TCP connection. The %X25-3-PVCBAD system error message (as documented in the System Error Messages publication), and the show x25 vc command (as documented in the Router Products Command Reference publication) also use these PVC state strings. Possible values follow:
awaiting PVC-SETUP reply can't support flow control values connected dest. disconnected dest. interface is not up dest. PVC configuration mismatch mismatched flow control values no such dest. interface no such dest. PVC non-X.25 dest. interface PVC setup protocol error PVC/TCP connect timed out PVC/TCP connection refused PVC/TCP routing error trying to connect via TCP waiting to connect |
| (29) | Incoming/outgoing message size (in bytes). |
| <Serial2 pvc 3> | Interface and PVC port that originated the message (originator). |
| <Serial2 pvc 1> | Interface and PVC port that responded to that message (responder). |
| 2/1 | Window size (in packets). |
| 128/64 | Maximum packet size (in bytes). |
Use the debug x25 events EXEC command to display information on all X.25 traffic except X.25 data or acknowledgment packets. The no form of this command disables debugging output.
debug x25 eventsThis command has no arguments or keywords.
EXEC
The debug x25 events command is useful for debugging X.25 problems, because it shows changes that occur in the virtual circuits handled by the router. Because most X.25 connectivity problems stem from errors that CLEAR or RESET virtual circuits, you can use debug x25 events to identify these errors.
While debug x25 all output includes both data and control messages for all of the router's virtual circuits, debug x25 events output includes only control messages for all of the router's VCs. In contrast, debug x25 vc output includes only control messages for a particular VC. Thus, debug x25 events output is a subset of debug x25 all output, and debug x25 vc output is a subset of debug x25 events output.
Figure 1-96 shows sample debug x25 events output.
See the debug x25 all command description for information on the fields in debug x25 events output.
Use the debug x25 vc EXEC command to display information on traffic for a particular virtual circuit in order to solve any connectivity or performance problems it is exhibiting. The no form of this command disables debugging output.
debug x25 vc number| number | LCI number associated with the virtual circuit(s) you want to monitor. |
EXEC
Because no interface is specified, traffic on any VC that has the specified number is reported.
While debug x25 all output includes both data and control messages for all of the router's virtual circuits, debug x25 events output includes only control messages for all of the router's VCs. In contrast, debug x25 vc output includes only control messages for a particular VC. Thus, debug x25 events output is a subset of debug x25 all output, and debug x25 vc output is a subset of debug x25 events output.
Figure 1-97 shows sample debug x25 vc output.
See the debug x25 all command description for information on the fields in debug x25 vc output.
|
|