debug v120 event

Use the debug v120 event EXEC command to display information on V.120 activity. The no form of this command disables debugging output.

Usage Guidelines

V.120 is an ITU specification that allows for reliable transport of synchronous, asynchronous, or bit transparent data over ISDN bearer channels.

For complete information on the V.120 process, use the debug v120 packet command along with the debug v120 event command. V.120 events are activity events rather than error conditions.

Sample Display

Figure 2-266 shows sample debug v120 event output of V.120 starting up and stopping. Also included is the interface that V.120 is running on (BR 0) and where the V.120 configuration parameters are obtained from (default).

Router# debug v120 event
0:01:47: BR0:1-v120 started - Setting default V.120 parameters
0:02:00: BR0:1:removing v120

Related Command

debug v120 packet

debug v120 packet

Use the debug v120 packet EXEC command to display general information on all incoming and outgoing V.120 packets. The no form of this command disables debugging output.

Usage Guidelines

The debug v120 packet command shows every packet on the V.120 session. You can use this information to determine whether incompatibilities exist between Cisco's V.120 implementation and other vendors' V.120 implementations.

V.120 is an ITU specification that allows for reliable transport of synchronous, asynchronous, or bit transparent data over ISDN bearer channels.

For complete information on the V.120 process, use the debug v120 events command along with the debug v120 packet command.

Sample Display

Figure 2-267 shows sample debug v120 packet output for a typical session startup.

Router# debug v120 packet
0:03:27: BR0:1: I SABME:lli 256 C/R 0 P/F=1
0:03:27: BR0:1: O UA:lli 256 C/R 1 P/F=1
0:03:27: BR0:1: O IFRAME:lli 256 C/R 0 N(R)=0 N(S)=0 P/F=0 len 43
0x83 0xD 0xA 0xD 0xA 0x55 0x73 0x65 
0x72 0x20 0x41 0x63 0x63 0x65 0x73 0x73 
0:03:27: BR0:1: I RR:lli 256 C/R 1 N(R)=1 P/F=0
0:03:28: BR0:1: I IFRAME:lli 256 C/R 0 N(R)=1 N(S)=0 P/F=0 len 2
0x83 0x63 
0:03:28: BR0:1: O RR:lli 256 C/R 1 N(R)=1 P/F=0
0:03:29: BR0:1: I IFRAME:lli 256 C/R 0 N(R)=1 N(S)=1 P/F=0 len 2
0x83 0x31 
0:03:29: BR0:1: O RR:lli 256 C/R 1 N(R)=2 P/F=0
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed state to up
0:03:31: BR0:1: I IFRAME:lli 256 C/R 0 N(R)=1 N(S)=2 P/F=0 len 2
0x83 0x55 
0:03:32: BR0:1: I IFRAME:lli 256 C/R 0 N(R)=1 N(S)=3 P/F=0 len 3
0x83 0x31 0x6F 
0:03:32: BR0:1: O RR:lli 256 C/R 1 N(R)=3 P/F=0
0:03:32: BR0:1: I IFRAME:lli 256 C/R 0 N(R)=1 N(S)=4 P/F=0 len 2
0x83 0x73 
0:03:32: BR0:1: O RR:lli 256 C/R 1 N(R)=5 P/F=0
0:03:32: BR0:1: I IFRAME:lli 256 C/R 0 N(R)=1 N(S)=5 P/F=0 len 2
0x83 0xA 
0:03:32: BR0:1: O IFRAME:lli 256 C/R 0 N(R)=6 N(S)=1 P/F=0 len 9
0x83 0xD 0xA 0x68 0x65 0x66 0x65 0x72 0x3E 

Table 2-138 describes the fields shown in the display.

Related Command

debug v120 event

debug vg-anylan

To monitor error information and 100VG connection activity, use the debug vg-anylan EXEC command. The no form of this command disables debugging output.

Usage Guidelines

This command could create large amounts of command output.

Sample Display

Figure 2-268 shows sample output from the debug vg-anylan command.

Router# debug vg-anylan
%HP100VG-5-LOSTCARR: HP100VG(2/0), lost carrier

Table 2-139 lists the possible messages that could be generated by this command.

debug vines arp

Use the debug vines arp EXEC command to display debugging information on all Virtual Integrated Network Service (VINES) Address Resolution Protocol (ARP) packets that the router sends or receives. The no form of this command disables debugging output.

Sample Display

Figure 2-269 shows sample debug vines arp output.

Router# debug vines arp
VNSARP: received ARP type 0 from 0260.8c43.a7e4
VNSARP: sending ARP type 1 to 0260.8c43.a7e4
VNSARP: received ARP type 2 from 0260.8c43.a7e4
VNSARP: sending ARP type 3 to 0260.8c43.a7e4 assigning address 3001153C:8004
VSARP: received ARP type 0 from 0260.8342.1501
VSARP: sending ARP type 1 to 0260.8342.1501
VSARP: received ARP type 2 from 0260.8342.1501
VSARP: sending ARP type 3 to 0260.8342.1501 assigning address 3001153C:8005, 
       sequence 143C, metric 2

In Figure 2-269, the first four lines show a non-sequenced ARP transaction and the second four lines show a sequenced ARP transaction. Within the first group of four lines, the first line shows that the router received an ARP request (type 0) from indicated 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.

Within the second group of four lines, the sequenced ARP packet also includes the router' current sequence number and the metric value between the router and the client.

Table 2-140 describes significant fields shown in Figure 2-269.

debug vines echo

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.

Sample Display

Figure 2-270 shows sample debug vines echo output.

Router# debug vines echo
VINESECHO: 100 byte packet from 0260.8c43.a7e4

Table 2-141 describes the fields shown in Figure 2-270.

debug vines ipc

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.

Usage Guidelines

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.

Sample Display

Figure 2-271 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.

Router# debug vines ipc
VIPC: sending IPC Data to Townsaver port 7 from port 7
 r_cid 0, l_cid 1, seq 1, ack 0, length 12
VIPC: received IPC Data from Townsaver port 7 to port 7
 r_cid 51, l_cid 1, seq 1, ack 1, length 32
VIPC: sending IPC Ack to Townsaver port 0 from port 0
 r_cid 51, l_cid 1, seq 1, ack 1, length 0

Table 2-142 describes the fields shown in Figure 2-271.

debug vines netrpc

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.

Usage Guidelines

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.

Sample Display

Figure 2-272 shows sample debug vines netrpc output. For more information about these fields or their values, refer to Banyan VINES documentation.

Router# debug vines netrpc
VRPC: sending RPC call to Townsaver
VRPC: received RPC return from Townsaver

Table 2-143 describes the fields shown in the first line of output in Figure 2-272.

debug vines packet

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.

Sample Display

Figure 2-273 shows sample debug vines packet output.

Router# debug vines packet
VINES: s=30028CF9:1 (Ether2), d=FFFFFFFF:FFFF, rcvd w/ hops 0
VINES: s=3000CBD4:1 (Ether1), d=3002ABEA:1 (Ether2), g=3002ABEA:1, sent
VINES: s=3000CBD4:1 (Ether1), d=3000B959:1, rcvd by gw
VINES: s=3000B959:1 (local), d=3000CBD4:1 (Ether1), g=3000CBD4:1, sent

Table 2-144 describes the fields shown in the first line of output.

Explanations for other lines in Figure 2-273 follow.

In the following line, 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 following line, the router being debugged is the destination address (3000B959:1):

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

In the following line, (local) indicates that the router being debugged generated the packet:

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

debug vines routing

Use the debug vines routing EXEC command to display information on all VINES 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.

Syntax Description

Sample Displays

Figure 2-274 shows sample debug vines routing output.

Figure 2-274: Sample Debug VINES Routing Output

Figure 2-275 shows sample debug vines routing verbose output.

Router# debug vines routing verbose
VRTP: sending update to Broadcast on Ethernet0
    network 30011E7E, metric 0020 (0.4000 seconds)
    network 30015800, metric 0010 (0.2000 seconds)
    network 3003148A, metric 0020 (0.4000 seconds)
VSRTP: generating change update, sequence number 0002C795
    network Router9        metric 0010, seq 00000000, flags 09
    network RouterZZ       metric 0230, seq 00052194, flags 02
VSRTP: sent update to Broadcast on Hssi0
VSRTP: received update from LabRouter on Hssi0
    update: type 00, flags 07, id 000E, ofst 0000, seq 15DFC, met 0010
    network LabRouter from the server
    network Router9        metric 0020, seq 00000000, flags 09
VSRTP: LabRouter-Hs0-HDLC up -> up, change update, onemore

Figure 2-275 describes two VINES routing updates; the first includes two entries and the second includes three entries. Explanations for selected lines of Figure 2-275 follow.

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

VRTP: sending update to Broadcast on Ethernet0
	

The following line indicates that the router knows how to reach network 30011E7E, which is a metric of 0020 away from the router. The value that follows the metric (0.4000 seconds) interprets the metric in seconds.

network 30011E7E, metric 0020 (0.4000 seconds)

The following lines show that the router sent a change routing update to the Broadcast addresses on the Hssi0 interface using the Sequenced Routing Update Protocol (SRTP) routing protocol:

VSRTP: generating change update, sequence number 0002C795
VSRTP: Sending update to Broadcast on Hssi0

The lines in between the previous two indicate that the router knows how to reach network Router9, which is a metric of 0010 (0.2000 seconds) away from the router. The sequence number for Router9 is zero, and according to the 0x08 bit in the flags field, is invalid. The 0x01 bit of the flags field indicates that Router9 is attached via a LAN interface.

network Router9        metric 0010, seq 00000000, flags 09

The next lines indicate that the router can reach network RouterZZ, which is a metric of 0230 (7.0000 seconds) away from the router. The sequence number for RouterZZ is 0052194. The 0x02 bit of the flags field indicates that RouterZZ is attached via a WAN interface.

network RouterZZ       metric 0230, seq 00052194, flags 02

The following line indicates that the router received a routing update from the router LabRouter through the Hssi0 interface:

VSRTP: received update from LabRouter on Hssi0

The following line displays all SRTP values contained in the header of the SRTP packet. This is a type 00 packet, which is a routing update, and the flags field is set to 07, indicating that this is a change update (0x04) and contains both the beginning (0x01) and end (0x02) of the update. This overall update is update number 000E from the router, and this fragment of the update contains the routes beginning at offset 0000 of the update. The sending router's sequence number is currently 00015DFC, and its configured metric for this interface is 0010.

update: type 00, flags 07, id 000E, ofst 0000, seq 00015DFC, met 0010

The following line 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, the other information for this entry is taken from the previous line.

network LabRouter from the server

As the first actual entry in the routing update from LabRouter, the following line indicates that Router9 can be reached by sending to this server. This network is a metric of 0020 away from the sending server.

network Router9        metric 0020, seq 00000000, flags 09

debug vines service

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.

Usage Guidelines

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.

Sample Display

Figure 2-276 shows sample debug vines service output.

Figure 2-276: Sample Debug VINES Service Output

As Figure 2-276 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 2-145 describes the fields shown in the second line of output in Figure 2-276. For more information about these fields or their values, refer to Banyan VINES documentation.

Table 2-146 describes the fields shown in the third line of output in Figure 2-276. 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.

debug vines state

Use the debug vines state EXEC command to display information on the VINES SRTP state machine transactions. The no form of this command disables debugging output.

Usage Guidelines

This command provides a subset of the information provided by the debug vines routing command, showing only the transactions made by the SRTP state machine. Refer to the debug vines routing command for descriptions of output from the debug vines state command.

debug vines table

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.

Usage Guidelines

This command provides a subset of the information produced by the debug vines routing command, as well as some more detailed information on table additions and deletions.

Sample Display

Figure 2-277 shows sample debug vines table output.

Router# debug vines table
VINESRTP: create neighbor 3001153C:8004, interface Ethernet0

Table 2-147 describes significant fields shown in Figure 2-277.

debug vlan packet

Use the debug vlan packet EXEC command to display general information on virtual LAN (VLAN) packets that the router received but is not configured to support. The no form of this command disables debugging output.

Usage Guidelines

The debug vlan packet command displays only packets with a VLAN identifier that the router is not configured to support. This command allows you to identify other VLAN traffic on the network. Virtual LAN packets that the router is configured to route or switch are counted and indicated when you use the show vlans command.

Sample Display

Figure 2-278 shows sample debug vlan packet output. In this example, a VLAN packet with a VLAN ID of 1000 was received on FDDI 0 interface and this interface was not configured to route or switch this VLAN packet.

Router# debug vlan packet
vLAN: IEEE 802.10 packet bearing vLAN ID 1000 received on interface
      Fddi0 which is not configured to route/switch ID 1000.

debug vpdn

To display debug traces for the Virtual Private Dialup Network (VPDN) feature, which provides PPP tunnels using the Layer 2 Forwarding (L2F) protocol, use the debug vpdn EXEC command. The no form of this command disables debugging output.

Syntax Description

Debug VPDN Events on a Network Access Server--Normal Operations

The network access server has the following VPDN configuration:

vpdn outgoing cisco.com stella ip 172.21.9.26 
username stella password stella 

Figure 2-279 shows sample output of the debug vpdn events command on a network access server when the L2F tunnel is brought up and CHAP authentication of the tunnel succeeds.

Router# debug vpdn events
%LINK-3-UPDOWN: Interface Async6, changed state to up
*Mar  2 00:26:05.537: looking for tunnel -- cisco.com --
*Mar  2 00:26:05.545: Async6 VPN Forwarding...
*Mar  2 00:26:05.545: Async6 VPN Bind interface direction=1
*Mar  2 00:26:05.553: Async6 VPN vpn_forward_user bum6@cisco.com is forwarded
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up
*Mar  2 00:26:06.289: L2F:  Chap authentication succeeded for stella.

Figure 2-280 shows sample output of the debug vpdn events command on a network access server when the L2F tunnel is brought down normally.

Router# debug vpdn events
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down
%LINK-5-CHANGED: Interface Async6, changed state to reset
*Mar  2 00:27:18.865: Async6 VPN cleanup
*Mar  2 00:27:18.869: Async6 VPN reset
*Mar  2 00:27:18.873: Async6 VPN Unbind interface
%LINK-3-UPDOWN: Interface Async6, changed state to down

Table 2-148 describes the fields in Figure 2-279 and Figure 2-280. The output describes normal operations when a tunnel is brought up or down on a network access server.

Debug VPDN Events on the Home Gateway--Normal Operations

The home gateway has the following VPDN configuration, which uses stella as the tunnel name and the tunnel authentication name. The tunnel authentication name might be entered in a users file on an AAA server and used to define authentication requirements for the tunnel.

vpdn incoming stella stella virtual-template 1

Figure 2-281 shows sample output of the debug vpdn events command on the home gateway when the tunnel is brought up successfully.

Router# debug vpdn events
L2F:  Chap authentication succeeded for stella.
Virtual-Access3 VPN Virtual interface created for bum6@cisco.com
Virtual-Access3 VPN Set to Async interface
Virtual-Access3 VPN Clone from Vtemplate 1 block=1 filterPPP=0
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
Virtual-Access3 VPN Bind interface direction=2
Virtual-Access3 VPN PPP LCP accepted sent & rcv CONFACK
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

Figure 2-282 shows sample output of the debug vpdn events command on a home gateway when the tunnel is brought down normally.

Router# debug vpdn events
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down
Virtual-Access3 VPN cleanup
Virtual-Access3 VPN reset
Virtual-Access3 VPN Unbind interface
Virtual-Access3 VPN reset
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down

Table 2-149 describes the fields in Figure 2-281 and Figure 2-282. The output describes normal operations when a tunnel is brought up or down on a network access server.

Debug VPDN L2F-Events on the Network Access Server--Normal Operations

Figure 2-283 shows sample output of the debug vpdn l2f-events command on the network access server when the L2F tunnel is brought up successfully.

Router# debug vpdn l2f-events
%LINK-3-UPDOWN: Interface Async6, changed state to up
*Mar  2 00:41:17.365: L2F Open UDP socket to 172.21.9.26
*Mar  2 00:41:17.385: L2F_CONF received
*Mar  2 00:41:17.389: L2F Removing resend packet (type 1)
*Mar  2 00:41:17.477: L2F_OPEN received
*Mar  2 00:41:17.489: L2F Removing resend packet (type 2)
*Mar  2 00:41:17.493: L2F building nas2gw_mid0
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up
*Mar  2 00:41:18.613: L2F_OPEN received
*Mar  2 00:41:18.625: L2F Got a MID management packet
*Mar  2 00:41:18.625: L2F Removing resend packet (type 2)
*Mar  2 00:41:18.629: L2F MID synced NAS/HG Clid=7/15 Mid=1 on Async6

Figure 2-284 shows sample output of the debug vpdn l2f-events command on a network access server when the tunnel is brought down normally.

Router# debug vpdn l2f-events
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down
%LINK-5-CHANGED: Interface Async6, changed state to reset
*Mar  2 00:42:29.213: L2F_CLOSE received
*Mar  2 00:42:29.217: L2F Destroying mid
*Mar  2 00:42:29.217: L2F Removing resend packet (type 3)
*Mar  2 00:42:29.221: L2F Tunnel is going down!
*Mar  2 00:42:29.221: L2F Initiating tunnel shutdown.
*Mar  2 00:42:29.225: L2F_CLOSE received
*Mar  2 00:42:29.229: L2F_CLOSE received
*Mar  2 00:42:29.229: L2F Got closing for tunnel 
*Mar  2 00:42:29.233: L2F Removing resend packet
*Mar  2 00:42:29.233: L2F Closed tunnel structure
%LINK-3-UPDOWN: Interface Async6, changed state to down
*Mar  2 00:42:31.793: L2F Closed tunnel structure
*Mar  2 00:42:31.793: L2F Deleted inactive tunnel

Table 2-150 describes the fields in Figure 2-283 and Figure 2-284.

Debug VPDN L2F-Events on the Home Gateway--Normal Operations

Figure 2-285 shows sample output of the debug vpdn l2f-events command on a home gateway when the L2F tunnel is created.

Router# debug vpdn l2f-events
L2F_CONF received
L2F Creating new tunnel for stella
L2F Got a tunnel named stella, responding
L2F Open UDP socket to 172.21.9.25
L2F_OPEN received
L2F Removing resend packet (type 1)
L2F_OPEN received
L2F Got a MID management packet
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Figure 2-286 shows sample output of the debug vpdn l2f-events command on a home gateway when the L2F tunnel is brought down normally.

Router# debug vpdn l2f-events
L2F_CLOSE received
L2F Destroying mid
L2F Removing resend packet (type 3)
L2F Tunnel is going down!
L2F Initiating tunnel shutdown.
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
L2F_CLOSE received
L2F Got closing for tunnel 
L2F Removing resend packet
L2F Removing resend packet
L2F Closed tunnel structure
L2F Closed tunnel structure
L2F Deleted inactive tunnel
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down

Table 2-151 describes the fields in Figure 2-285 and Figure 2-286.

Debug VPDN on the Network Access Server--Error Conditions

Figure 2-287 shows sample output of the debug vpdn errors command on a network access server when the tunnel is not set up.

Router# debug vpdn errors
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to down
%LINK-5-CHANGED: Interface Async1, changed state to reset
%LINK-3-UPDOWN: Interface Async1, changed state to down
%LINK-3-UPDOWN: Interface Async1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up
VPDN tunnel management packet failed to authenticate
VPDN tunnel management packet failed to authenticate
 

Table 2-152 describes the fields in Figure 2-287.

Figure 2-288 shows sample output of the debug vpdn l2f-errors command.

Router# debug vpdn l2f-errors
%LINK-3-UPDOWN: Interface Async1, changed state to up
L2F Out of sequence packet 0 (expecting 0)
L2F Tunnel authentication succeeded for home.com
 L2F Received a close request for a non-existent mid
 L2F Out of sequence packet 0 (expecting 0)
 L2F packet has bogus1 key 1020868 D248BA0F
L2F packet has bogus1 key 1020868 D248BA0F
 

Table 2-153 describes the fields in Figure 2-288.

Debugging VPDN Packets for Complete Information

Figure 2-289 shows sample output of the debug vpdn l2f-packets command on a network access server. This example displays a trace for a ping command.

Router# debug vpdn l2f-packets
L2F SENDING (17): D0 1 1 10 0 0 0 4 0 11 0 0 81 94 E1 A0 4
L2F header flags: 53249 version 53249 protocol 1 sequence 16 mid 0 cid 4
length 17 offset 0 key 1701976070
L2F RECEIVED (17): D0 1 1 10 0 0 0 4 0 11 0 0 65 72 18 6 5
L2F SENDING (17): D0 1 1 11 0 0 0 4 0 11 0 0 81 94 E1 A0 4
L2F header flags: 53249 version 53249 protocol 1 sequence 17 mid 0 cid 4
length 17 offset 0 key 1701976070
L2F RECEIVED (17): D0 1 1 11 0 0 0 4 0 11 0 0 65 72 18 6 5
L2F header flags: 57345 version 57345 protocol 2 sequence 0 mid 1 cid 4
length 32 offset 0 key 1701976070
L2F-IN Otput to Async1 (16): FF 3 C0 21 9 F 0 C 0 1D 41 AD FF 11 46 87
L2F-OUT (16): FF 3 C0 21 A F 0 C 0 1A C9 BD FF 11 46 87
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 32 offset 0 key -2120949344
L2F-OUT (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 3 1 0 0 1 8 0 62 B1
0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB
CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 120 offset 3 key -2120949344
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 120 offset 3 key 1701976070
L2F-IN Output to Async1 (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 1 1 0
0 3 0 0 6A B1 0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD
AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB
CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
 

Table 2-154 describes the fields in Figure 2-289.

Related Commands

debug aaa authentication
debug ppp authentication
debug ppp negotiations
debug ppp error

debug vtemplate

To display cloning information for a virtual access interface from the time it is cloned from a virtual template to the time the virtual access interface comes down when the call ends, use the debug vtemplate privileged EXEC command. The no form of this command disables debugging output.

Sample Displays

Figure 2-290 shows sample output from the debug vtemplate command when a virtual access interface come up. The virtual access interface is cloned from virtual template 1.

Router# debug vtemplate
VTEMPLATE Reuse vaccess8, New Recycle queue size:50
 
VTEMPLATE set default vaccess8 with no ip address
 
Virtual-Access8 VTEMPLATE hardware address 0000.0c09.ddfd
VTEMPLATE vaccess8 has a new cloneblk vtemplate, now it has vtemplate
VTEMPLATE undo default settings vaccess8
 
VTEMPLATE ************* CLONE VACCESS8 *****************
 
VTEMPLATE Clone from vtemplate1 to vaccess8
interface Virtual-Access8
no ip address
encap ppp
ip unnumbered Ethernet0
no ip mroute-cache
fair-queue 64 256 0
no cdp enable
ppp authentication chap
end
 
%LINK-3-UPDOWN: Interface Virtual-Access8, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access8, changed state to up

Figure 2-291 shows sample output from the debug vtemplate command when a virtual access interface goes down. The virtual interface is uncloned and returns to the recycle queue.

Router# debug vtemplate
%LINK-3-UPDOWN: Interface Virtual-Access8, changed state to down
VTEMPLATE Free vaccess8
 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access8, changed state to down
VTEMPLATE clean up dirty vaccess queue, size:1
 
VTEMPLATE Found a dirty vaccess8 clone with vtemplate
VTEMPLATE ************ UNCLONE VACCESS8 **************
VTEMPLATE Unclone to-be-freed vaccess8 command#7
interface Virtual-Access8
default ppp authentication chap
default cdp enable
default fair-queue 64 256 0
default ip mroute-cache
default ip unnumbered Ethernet0
default encap ppp
default ip address
end
 
VTEMPLATE set default vaccess8 with no ip address
 
VTEMPLATE remove cloneblk vtemplate from vaccess8 with vtemplate
 
VTEMPLATE Add vaccess8 to recycle queue, size=51

Table 2-155 explains the lines in Figure 2-290 and Figure 2-291.

debug x25

To display information about X.25 traffic, use one of the following debug x25 commands. The commands allow you to display all information or an increasingly restrictive part of the information.

Caution  This command is processor intensive and can render the router useless. Use this command only when the aggregate of all reportable X.25 traffic is fewer than five packets per second. The generic forms of this command should be restricted to low-speed, low-usage links running below 19.2 kbps. Because the debug x25 vc command and the debug x25 vc events command display traffic for only a small subset of virtual circuits, they are safer to use under heavy traffic conditions, as long as events for that virtual circuit are fewer than 25 packets per second.

To display information about all X.25 traffic, including traffic for X.25, CMNS, and XOT services, use the debug x25 EXEC command. To disable debugging output, use the no form of this command.

To display information about a specific X.25 service class, use the following form of the debug x25 EXEC command:

To display information about a specific X.25 or CMNS context, use the following form of the debug x25 EXEC command:

To display information about a specific X.25 or CMNS virtual circuit, use the following form of the debug x25 EXEC command:

To display information about traffic for all virtual circuits using a given number, use the following form of the debug x25 EXEC command. The no form of this command removes the filter for a particular virtual circuit from the debug x25 all or debug x25 events output:

To display information about traffic to or from a specific XOT host, use the following form of the debug x25 xot EXEC command:

Syntax Description

Usage Guidelines

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.

All debug x25 command forms can take either the events or all keyword. The keyword all is the default and causes all packets meeting the other debug criteria to be reported. The keyword events omits reports of any Data or Receive Ready (RR) flow control packets; the normal flow of Data and RR packets is commonly large as well as less interesting to the user, so event reporting can significantly decrease the processor load induced by debug reporting.

The debug x25 interface command is useful for diagnosing problems encountered with a single X.25 or CMNS host or virtual circuit.

Because no interface is specified by the debug x25 vc command, traffic on any virtual circuit that has the specified number is reported.

Virtual circuit zero (vc 0) cannot be specified. It is used for X.25 service messages, such as RESTART packets, not virtual circuit traffic. Service messages can be monitored only when no virtual circuit filter is used.

The debug x25 xot output allows you to restrict the debug output reporting to XOT traffic for one or both hosts or host/port combinations. Because each XOT virtual circuit uses a unique TCP connection, an XOT debug request that specifies both host addresses and ports will report traffic only for that virtual circuit. Also, you can restrict reporting to sessions initiated by the local or remote router by, respectively, specifying 1998 for the remote or local port. (XOT connections are received on port 1998.)

Sample Display

Figure 2-292 shows the debug output for an X.25 Restart event, a Call setup, data exchange, and Clear. The first two lines describe a Restart service exchange.

Router# debug x25
Serial0: X.25 I R/Inactive Restart (5) 8 lci 0
  Cause 7, Diag 0 (Network operational/No additional information)
Serial0: X.25 O R3 Restart Confirm (3) 8 lci 0
Serial0: X.25 I P1 Call (15) 8 lci 1
From(6): 170091 To(6): 170090
   Facilities: (0)
   Call User Data (4): 0xCC000000 (ip)
Serial0: X.25 O P3 Call Confirm (3) 8 lci 1
Serial0: X.25 I D1 Data (103) 8 lci 1 PS 0 PR 0
Serial0: X.25 O D1 Data (103) 8 lci 1 PS 0 PR 1
Serial0: X.25 I P4 Clear (5) 8 lci 1
  Cause 9, Diag 122 (Out of order/Maintenance action)
Serial0: X.25 O P7 Clear Confirm (3) 8 lci 1

Table 2-156 describes the fields in Figure 2-292.

The following example shows a sequence of increasingly restrictive debug x25 commands:

Router# debug x25
X.25 packet debugging is on
Router# debug x25 events
X.25 special event debugging is on
Router# debug x25 interface serial 0
X.25 packet debugging is on
X.25 debug output restricted to interface Serial0 
Router# debug x25 vc 1024
X.25 packet debugging is on
X.25 debug output restricted to VC number 1024 
Router# debug x25 interface serial 0 vc 1024
X.25 packet debugging is on
X.25 debug output restricted to interface Serial0 
X.25 debug output restricted to VC number 1024 
Router# debug x25 interface serial 0 vc 1024 events
X.25 special event debugging is on
X.25 debug output restricted to interface serial 0 
X.25 debug output restricted to VC number 1024

debug x28

Use the debug x28 privileged EXEC command to monitor error information and X.28 connection activity. The no form of this command disables debugging output.

Sample Display

Figure 2-293 shows sample output while the PAD initiates an X.28 outgoing call.

Router# debug x28
X28 MODE debugging is on
Router# x28
*
03:30:43: X.28 mode session started
03:30:43: X28 escape is exit
03:30:43: Speed for console & vty lines :9600 
*call 123456
COM
03:39:04: address ="123456", cud="[none]" 03:39:04: Setting X.3 Parameters for this call...1:1 2:1 3:126 4:0 5:1 6:2 7:2 8:0 9:0 10:0 11:14 12:1 13:0 14:0 15:0 16:127 17:24 18:18 19:2 20:0 21:0 22:0 
Router> exit
CLR CONF
*
*03:40:50: Session ended
* exit
Router#
*03:40:51: Exiting X.28 mode

debug xns packet

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.

Usage Guidelines

To gain the fullest understanding of XNS routing activity, you should enable debug xns routing and debug xns packet together.

Sample Display

Figure 2-294 shows sample debug xns packet output.

Router# debug xns packet
XNS: src=5.0000.0c02.6d04, dst=5.ffff.ffff.ffff, packet sent
XNS: src=1.0000.0c00.440f, dst=1.ffff.ffff.ffff, rcvd. on Ethernet0
XNS: src=1.0000.0c00.440f, dst=1.ffff.ffff.ffff, local processing

Table 2-157 describes significant fields shown in Figure 2-294.

debug xns routing

Use the debug xns routing EXEC command to display information on XNS routing transactions. The no form of this command disables debugging output.

Usage Guidelines

To gain the fullest understanding of XNS routing activity, enable debug xns routing and debug xns packet together.

Sample Display

Figure 2-295 shows sample debug xns routing output.

Router# debug xns routing
XNSRIP: sending standard periodic update to 5.ffff.ffff.ffff via Ethernet2
 network 1, hop count 1
 network 2, hop count 2
XNSRIP: got standard update from 1.0000.0c00.440f socket 1 via Ethernet0
 net 2: 1 hops

Table 2-158 describes significant fields shown in Figure 2-295.