Worldwide [change] |Account |Register |About Cisco
Guest

Hierarchical Navigation

ATM Signaling

Troubleshooting SSCOP Errors and LANE Client Resets on ATM Interfaces

Downloads

Document ID: 10504


Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Step 1 - The show sscop Command
      Begin Counter
      Begin Reject Counter
      End Counter
      Poll Counter
      Stat Counter
      UStat Counter
      Unknown PDU Counter
Step 2 - The show interface atm Command
Step 3 - The show controller atm Command
Step 4 - Other debug Commands
Understanding debug sscop packet Output
Understanding maaError Codes
      maaError-P
      maaError-V
      maaError-R
      maaError-S
Sample Output 1
Sample Output 2
High CPU Utilization
Related Information

Introduction

This document provides tips on how to troubleshoot unexpected ATM LAN Emulation Client (LEC) state changes and the accompanying messages printed to the router's log. Here is an example:

Jan 25 16:41:27: %ATMSSCOP-5-SSCOPINIT: - Intf : 4/0, Event : Rcv End, State : Active. 
Jan 25 16:41:27: %LANE-5-UPDOWN: ATM4/0.141 elan test1: LE Client changed state to down 
Jan 25 16:41:27: %LANE-5-UPDOWN: ATM4/0.133 elan test2: LE Client changed state to down

In the above messages, Rcv End indicates that the router received an End protocol data unit (PDU), which is part of the Service Specific Connection-Oriented Protocol (SSCOP). See Understanding SSCOP Messages on Router ATM Interfaces for more information on SSCOP.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Step 1 - The show sscop Command

Begin your troubleshooting by collecting the output of the show sscop command on both devices of a physical connection. This command displays the state of SSCOP on each interface. The following sample output was captured on a healthy LightStream 1010 ATM switch and a PA-A3 port adapter.

Note: There are no Error Recovery PDUs sent or acknowledged and no lack of credit errors.

	lt-c5500asp-13a#show sscop atm12/0/2
      SSCOP details for interface ATM12/0/2 
      Current State = Active,   Uni version = 3.1    
      
! -- Confirm that Current State = Active.
    
      Send Sequence Number: Current = 0, Maximum = 30    
      Send Sequence Number Acked = 0 
      Rcv Sequence Number: Lower Edge = 0, Upper Edge = 0, Max = 30 
      Poll Sequence Number = 22, Poll Ack Sequence Number = 22    
      Vt(Pd) = 0   Vt(Sq) = 1 
      Timer_IDLE = 10 - Active 
      Timer_CC = 1 - Inactive 
      Timer_Poll = 1000 - Inactive 
      Timer_KEEPALIVE = 5 - Inactive 
      Timer_NO-RESPONSE = 45 - Inactive 
      Current Retry Count = 0, Maximum Retry Count = 10 
      AckQ count = 0, RcvQ count = 0, TxQ count = 0 
      AckQ HWM = 0,  RcvQ HWM = 0, TxQ HWM = 0 
      Local connections currently pending = 0 
      Max local connections allowed pending = 0 
      Statistics - 
         Pdu's Sent = 23, Pdu's Received = 23, Pdu's Ignored = 0 
         Begin = 0/1, Begin Ack = 1/0, Begin Reject = 0/0 
         End = 0/0, End Ack = 0/0 
         Resync = 0/0, Resync Ack = 0/0 
         Sequenced Data = 0/0, Sequenced Poll Data = 0/0 
         Poll = 22/22, Stat = 22/22, Unsolicited Stat = 0/0    
      
! -- Confirm that the number of received Stat PDUs equals the number of sent Poll PDUs. 

      
! -- Also confirm that there are no received or sent UStat PDUs.   
 
         Unassured Data = 0/0, Mgmt Data = 0/0, Unknown Pdu's = 0 
         Error Recovery/Ack = 0/0, lack of credit 0    

        lt-7204-15a#show sscop 
        SSCOP details for interface ATM2/0 
        Current State = Active,   Uni version = 3.1      
        Send Sequence Number: Current = 0,  Maximum = 30      
        Send Sequence Number Acked = 0 
        Rcv Sequence Number: Lower Edge = 0, Upper Edge = 0, Max = 30 
        Poll Sequence Number = 43, Poll Ack Sequence Number = 43      
        Vt(Pd) = 0   Vt(Sq) = 0 
        Timer_IDLE = 10 - Active 
        Timer_CC = 1 - Inactive 
        Timer_Poll = 1000 - Inactive 
        Timer_KEEPALIVE = 5 - Inactive 
        Timer_NO-RESPONSE = 45 - Inactive 
        Current Retry Count = 0, Maximum Retry Count = 10 
        AckQ count = 0, RcvQ count = 0, TxQ count = 0 
        AckQ HWM = 0,  RcvQ HWM = 0, TxQ HWM = 0 
        Local connections currently pending = 0 
        Max local connections allowed pending = 0 
        Statistics - 
           Pdu's Sent = 44, Pdu's Received = 44, Pdu's Ignored = 0 
           Begin = 1/0, Begin Ack = 0/1, Begin Reject = 0/0 
        
! -- This interface received one BGN PDU and sent one BGN ACK to start the session. 
   
         End = 0/0, End Ack = 0/0 
         Resync = 0/0, Resync Ack = 0/0 
         Sequenced Data = 0/0, Sequenced Poll Data = 0/0 
         Poll = 44/43, Stat = 43/44, Unsolicited Stat = 0/0 
         Unassured Data = 0/0, Mgmt Data = 0/0, Unknown Pdu's = 0 
         Error Recovery/Ack = 0/0, lack of credit 0

If the current state is not Active on the PA-A3, use the following steps on the router to determine why:

  1. Confirm that the interface is configured with an active signaling permanent virtual circuit (PVC). This VC is configured with special signaling ATM adaptation (SAAL) encapsulation.

    7204#show atm vc
           VCD /                                   Peak Avg/Min Burst 
   Interface  Name   VPI   VCI  Type      Encaps   Kbps   Kbps  Cells      Sts 
   2/0            1      0     5   PVC    SAAL        149760                UP 
   2/0            2      0    16   PVC    ILMI        149760                UP

  2. Execute the show atm vc <vcd> command on the QSAAL PVC. Confirm non-zero and incrementing values for InPkts and OutPkts.

    7204#show atm vc 1
   ATM2/0: VCD: 1, VPI: 0, VCI: 5 
   UBR, PeakRate: 149760 
   AAL5-SAAL, etype:0x4, Flags: 0xC25, VCmode: 0x0 
   OAM frequency: 0 second(s) 
   InARP DISABLED 
   Transmit priority 1 
   InPkts: 522, OutPkts: 522, InBytes: 7300, OutBytes: 5208    
   InPRoc: 522, OutPRoc: 522, Broadcasts: 0 
   InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 
   InPktDrops: 0, OutPktDrops: 0 
   CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 
   Out CLP=1 Pkts: 0 
   OAM cells received: 0 
   OAM cells sent: 0 
   Status: UP

  3. Execute the show interface atm command and confirm that the ATM interface is in an Up/Up state.

If the current state is not Active on the LightStream 1010, use the following steps to determine why:

  1. Execute the show atm vc traffic interface atm command for the QSAAL or signaling VC and confirm non-zero and incrementing values for the rx-cell-cnts and tx-cell-cnts values.

    lt-8510-12a#show atm vc traffic interface atm 0/0/0 
     Interface         VPI      VCI        Type      rx-cell-cnts    tx-cell-cnts      
     ATM0/0/0          0         5     PVC                   0                 0 
     ATM0/0/0          0         16    PVC                   0            731159      
     ATM0/0/0          21        202   PVC               266564           279750

  2. Use the show sscop command to determine the values of the five SSCOP timers that control operation of the protocol. Cisco recommends the use of matching values on peer interfaces.

    Confirm that both ends of the VC are using the same User Network Interface (UNI) version. Cisco devices support either auto negotiation or manual configuration of the UNI version. If the UNI versions do not match, the router reports the following log messages and terminates the SSCOP connection:

    4d23h: %ATMSSCOP-4-UNMATCHUNIVERSION: (ATM2/0): rcv non-0 NUU in BeginPdu at UNI 
   4d23h: %ATMSSCOP-5-SSCOPINIT: - Intf : ATM2/0, Event : Rcv End, State : Active. 
   4d23h: %LANE-6-INFO: ATM2/0: ILMI prefix add event received

    When manually setting the UNI version on a router interface, first disable atm auto-configuration.

    interface atm2/0 
       atm pvc 0/5 qsaal 
       atm pvc 0/16 ilmi 
       no atm auto-configuration 
       atm uni-version 3.1

    Note: SSCOP also operates over Network-to-Network Interface (NNI) connections between two ATM switches. The output of show sscop from an NNI interface displays a UNI version eventhough the interface is configured as NNI.

    Confirm matching values for the Poll and Poll ACK sequence numbers. The Poll ACK number may be one number lower than the Poll sequence number. Confirm that both numbers are increasing. Non-matching numbers indicate a problem with receiving Poll ACKs from the peer device. Check the values of the peer device using the show sscop command.

    One reason for not receiving Poll ACKs is lack of credit errors at the peer. The lack of credit counter indicates that the transmit window of the sender was full. It normally increases during a burst of signaling packets on the link and as such does not indicate a problem. An ATM device transmits an SSCOP PDU only after confirming that the peer can receive it. If the peer cannot receive the packet, then the packet is queued.

    However, if two peer devices show incrementing lack of credit values that cannot be attributed to increased signaling activity, there may be a communication problem between the two peers. Start by checking the cable, and then try enabling debug sscop error atm <interface> .

Begin Counter

The Begin and Begin Ack counters display received and sent (in/out) information for Begin and Begin Ack PDUs. Under normal operation, you should see one peer initiate the session by sending a Begin PDU, and the other side reply with the Begin Ack.

If the Begin and Begin Ack counters are greater than one, the SSCOP session was restarted either due to an SSCOP problem or to a manual shutdown and no shutdown of the ATM interfaces. Other reasons for SSCOP session restarts include:

  • Receipt of an End PDU due to protocol errors.

  • Failure to receive Stat PDUs for the Timer_NO-RESPONSE interval.

  • Receipt of PDUs with sequence errors.

Begin Reject Counter

This counter displays the number of Begin Reject PDUs received and sent by this peer. Incrementing values for the Begin Reject PDU received counter suggests that the remote interface is rejecting the SSCOP session establishment request, while an incrementing value for Begin Reject PDUs sent indicates that the local device is rejecting the SSCOP session establishment request. Troubleshoot this problem by ensuring both peers are using the same UNI version. Also try enabling debug sscop error atm <interface> to determine the cause of the Begin Reject.

End Counter

The End and End ACK counters display the number of times the the device has received/sent End and End Ack PDUs. These counters indicate that the sending device terminated an established SSCOP session. Investigate the cause of the End PDU. Receiving an End PDU causes the ATM interface to release all SVCs.

Possible causes for a peer sending an End PDU include the following:

  • Disabled or shutdown peer interface

  • Input interface errors

  • Faulty cabling

  • Faulty hardware

  • High CPU utilization

  • Software defect

Poll Counter

This counter indicates the number of Poll PDU received and sent. Ensure that the number of Poll PDUs sent equals to or is one number higher than the number of Stat PDUs received. Likewise, the number of Poll PDUs received should be equal to or one greater than the number of Stat PDUs sent. Non-matching values suggests packet loss between the peer interfaces.

Stat Counter

The Stat Counter indicates the number of Stat PDU received and sent and is indicated in received/sent format. The number of Stat PDUs sent should be equal to or one less than the number of Poll PDUs received. Likewise, the number of Stat PDUs received should be equal to or one less than the number of Poll PDUs sent.

Mismatched values for the Poll and Stat PDU counters point to a problem with packet loss between the peers.

UStat Counter

This counter indicates the number of Unsolicited Stat PDUs received and sent. Incrementing and non-zero values for the Unsolicited Stats sent or received counter points to a communication problem between the two peers. Specifically, it suggests that one peer failed to receive all the signaling data (SD PDUs) sent by the far-end. The lost SD PDUs were resent by the peer that received the Ustat PDU.

Unknown PDU Counter

This counter indicates that the local interface received a unrecognizable PDU with an invalid PDU type code. Troubleshoot this problem by first ensuring that the peers are running the same UNI version. If so, then determine whether the problem is caused by a software error. Specifically, use an ATM sniffer in line between the two devices and try to capture the packet that is generating the error. If your ATM device supports a low amount of signaling activity, try enabling debug sscop packet.

caution Caution: Before issuing debug commands, please see Important Information on Debug Commands. The debug sscop packet command may print a large amount of disruptive debug output on a production router depending on the amount of signaling activity. Disable console logging with the no logging console and enable logging to the buffer instead with logging buffered in global configuration mode.

Step 2 - The show interface atm Command

Input errors are the most common cause of SSCOP errors and unexpected LANE client resets. Execute the show interface atm command on both peer interfaces and look for non-zero values for the input error counters.

7204#show interface atm 2/0
     ATM2/0 is up, line protocol is up 
     Hardware is ENHANCED ATM PA, address is 0010.117e.0038 (bia 0010.117e.0038)    
     MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec, rely 255/255, load5 
     Encapsulation ATM, loopback not set 
     Keepalive not supported 
     Encapsulation(s): AAL5 
     4096 maximum active VCs, 2 current VCCs 
     VC idle disconnect time: 300 seconds 
     Signalling vc = 1, vpi = 0, vci = 5 
     UNI Version = 3.1, Link Side = user 
     0 carrier transitions 
     Last input 00:00:01, output 00:00:01, output hang never 
     Last clearing of "show interface" counters 00:00:13 
     Queueing strategy: fifo 
     Output queue 0/40, 0 drops; input queue 0/75, 0 drops    
     5 minute input rate 0 bits/sec, 0 packets/sec 
     5 minute output rate 0 bits/sec, 0 packets/sec 
        3 packets input, 40 bytes, 0 no buffer    
        Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
        3 packets output, 32 bytes, 0 underruns 
        0 output errors, 0 collisions, 0 interface resets    
        0 output buffer failures, 0 output buffers swapped out

Refer to the following URLs for assistance with troubleshooting input errors:

A non-zero value for the "ignored" counter indicates that the interface ran out of packet buffers. These buffers are different than the system buffers. Excessive numbers of ignored packets can lead to SSCOP session resets.

Step 3 - The show controller atm Command

Cisco ATM switch routers, which include the LightStream 1010 and the Catalyst 8500 series, use a switching fabric with a shared-memory architecture. In some cases, the switch drops cells and increments the invalid cells counter, as shown in the output of one of the following commands depending on the platform:

  • show switch fabric - Catalyst 8540

  • show controller atm 2/0/0 - LightStream 1010

  • show controller controller0 - Catalyst 8510

Determine whether the invalid cell counter points to the QSAAL VC, which uses VPI=0 and VCI=5 by default. See Troubleshooting Invalid Cells on ATM Switch Routers for guidance.

8510#show controller atm2/0/0 
    MMC Switch Fabric (idb=0x61314560)    
    Key: discarded cells  - # cells discarded due to lack of resources or policing (16-bit) 
         invalid cells - # good cells that came in on a non-existent conn. 
         memory buffer - # cell buffers currently in use 
         RXcells - # rx cells (16-bit) 
         TXcells - # tx cells (16-bit) 
         RHEC - # cells with HEC errors 
         TPE - # cells with memory parity errors    
      discarded cells = 0 
      invalid cells   = 519604 
      memory buffer   = 0 
      garbage cells to cpu = 0 
      unexpected marker intrs = 0 
      # marker intrs = 1218, requested = 1218 
      # marker list entries = 0 
      # marker queue full cond = 0 
      # ivcs used: total=10, low=4, high=6 
      # ovcs used: total=10, even=10, odd=0 
      # vpts used: total=0, even=0, odd=0 
      # vpt ovcs used: total=0, even=0, odd=0 
      # free sch reserved: total=0, even=0, odd=0 
      # free sch used: total=0, even=0, odd=0 
      port   type   status RXcells TXcells RHEC   TPE  PACE_I PACE_M PACE_X PACE_Y 
      0/0/0 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/0/1 155MBPS xytrpm 0x538D 0x546F 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/0/2 155MBPS xytrpm 0x9E2E 0x9A84 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/0/3 155MBPS xytrpm 0xC748 0xCC30 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/1/4 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/1/5 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/1/6 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      0/1/7 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      1/1/4 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      1/1/5 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      1/1/6 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      1/1/7 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      2/0/0 CPU                 0x221399B 0x4597B25 
      3/1/4 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      3/1/5 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      3/1/6 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      3/1/7 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      4/1/4 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      4/1/5 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      4/1/6 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
      4/1/7 155MBPS xytrpm 0x733A 0xCC3C 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 00 
     Invalid Cell Log 
     time stamp               port  pt clp gfc  vpi vci      
     1 0xBD3D2457.0xF02757C0 0/0/1 0x1 0x0 0x0 0x15 0xCA 
     2 0xBD3D2459.0xF0275570 0/0/1 0x6 0x0 0x0 0x15 0xCA 
     3 0xBD3D245B.0xF0275320 0/0/1 0x1 0x0 0x0 0x15 0xCA 
     4 0xBD3D245D.0xF02750D0 0/0/1 0x6 0x0 0x0 0x15 0xCA 
     5 0xBD3D245F.0xF0274E80 0/0/1 0x1 0x0 0x0 0x15 0xCA 
     6 0xBD3D2461.0xF0274C30 0/0/1 0x6 0x0 0x0 0x15 0xCA 
     [output omitted]

The memory buffer counter is a non-zero value that varies with the traffic rates and types of connections. A high value is common when traffic rates are above line rate (considering periodic Interim Local Management Interface [ILMI] and SSCOP traffic).

The TPE counter displays the number of cells received on each interface with memory parity errors. A non-zero value for the TPE counter may indicate faulty hardware. Try rebooting the system and determine whether power-on diagnostics reports a failure. TPE errors on only one or two ports point to a faulty port adapter module (PAM). TPE errors on many ports points to a faulty ATM switch processor (ASP). See Troubleshooting ASP Red Status Light and Power-on Diagnostic Problems on the LightStream 1010 and Catalyst 8510-MSR.

A rapidly incrementing value for the discarded cells counter suggests that an ATM switch is running out of resources or has exceeded thresholds such as lack of cell memory, maxed-out queues, usage parameter control (UPC) violations, and so on. This counter wraps at 65536 and should be used simply as a guide to inform you that you are sending more traffic than you should be. See Understanding Rejected/Discarded Cell Counters on ATM Switch Router.

The VC that carries signaling packets terminates on the ATM switch. With terminating connections, cells being discarded also are counted in a non-zero no buffer field of the show int atm 2/0/0 command. A non-zero value for the no buffer field indicates that the system buffers used by Cisco IOS for reassembled ATM adaptation layer 5 (AAL5) frames ran out of resources, and the entire AAL5 packet was dropped.

Step 4 - Other debug Commands

The following debug commands also can be used to troubleshoot SSCOP and LANE client resets.

  • debug sscop errors

  • debug atm sig-error

  • debug atm errors

These debugs only generate console output in the event of errors and normally can be run safely on production routers and switches.

Cisco recommends the following when enabling SSCOP debugs:

  • Enable msec timestamps.

    ROUTER(config)# service timestamps debug datetime msec
ROUTER(config)# service timestamps log datetime msec

  • Disable logging to the console. Enable buffer logging.

    ROUTER(config)# no logging console
ROUTER(config)# logging buffered 16000

  • Clear the log.

    ROUTER# clear log

  • Enable SSCOP error debugs on a particular interface only.

    ROUTER# debug sscop error atm<interface>.

When debug atm sig-error is enabled, the device may report an invalid PDU using the following message:

ATMSIG: incoming msg has invalid protocol discriminator 0

This message indicates that SSCOP has passed a PDU that the signaling layer does not recognize as a valid message. This error may occur during heavy signaling loads, and no feature failure results.

Understanding debug sscop packet Output

The debug sscop packet <interface> and debug sscop events <interface> commands can provide useful troubleshooting information. However, take care when enabling these debugs. A large amount of debug output can cause SSCOP failures if the CPU becomes too busy to process PDUs. Enable these debugs only on specific interfaces. Alternatively, in production networks with large amounts of signaling activity, use an inline ATM protocol analyzer to collect SSCOP packets between peers.

The output of debug sscop packet produces hexadecimal output of SSCOP packets. The International Telecommunications Union (ITU-T) defines the format of SSCOP packets in its Q.2110 standard. The format for Poll PDUs and Stat PDUs is shown below.

Poll PDU

00 XX XX XX 0A YYYYYY

  • XXXXXX = N(PS) - Poll Send Sequence Number (Convert from hexadecimal to decimal).

  • YYYYYY = N(S) - Sequence Data Send Sequence Number (Convert from hexadecimal to decimal).

Stat PDU

00 XXXXXX 00 YYYYYY 0B ZZZZZZ

  • XXXXXX = N(PS) - Poll Send Sequence Number.

  • YYYYYY = N(MR) - Specifies the size of the credit window.

  • ZZZZZZ = N(R) - Buffer release parameter.

The following sample output was captured on a PA-A3 connected to a LightStream 1010 switch. The two devices transmit Poll PDUs every ten seconds since the state is idle. If signaling activity were occurring between the devices, then each device would send Poll PDUs every Timer_Poll, which is one second by default.

*Jul 11 16:13:00.005: SSCOP(ATM2/0): o Poll pdu, state = Active, 
   n(s) = 0, n(ps) = 1307 
   *Jul 11 16:13:00.005: SSCOP(O - ATM2/0): 00 00 05 1B 0A 00 00 00 
   
! -- The router outputs a Poll PDU N(PS) = 1307.
    
   *Jul 11 16:13:00.005: SSCOP(I - ATM2/0): 00 00 05 1B 00 00 00 1E 0B 00 00 00 
   
! -- The router receives a Stat PDU N(PS) = 1307.
    
   *Jul 11 16:13:00.005: SSCOP(ATM2/0): i Stat pdu, Active state, length = 12 
   *Jul 11 16:13:00.005: SSCOP(ATM2/0): Rcv Stat in Active State 
   *Jul 11 16:13:00.005: SSCOP(ATM2/0): processStatPdu: ps 1307, nmr 30, nr 0 
   *Jul 11 16:13:00.005: SSCOP(ATM2/0): processStatPdu: vtPa 1306, vps 1307    
   *Jul 11 16:13:00.005: SSCOP(ATM2/0): processStatPdu: vta 0, vts 0 
   *Jul 11 16:13:00.005: SSCOP(ATM2/0): processStatPdu: listCount = 0 - normal    
   *Jul 11 16:13:02.461: SSCOP(O - ATM2/0): 00 00 05 1B 0A 00 00 00 
   *Jul 11 16:13:02.461: SSCOP(ATM2/0): * Poll pdu, ns = 0, nps = 1307    
   
! -- The debug marks this packet with an O indicating outbound even though it is 
   ! -- an incoming Poll PDU. 

   *Jul 11 16:13:02.461: SSCOP(ATM2/0): o Stat pdu, n(r) = 0, n(mr) = 30, n(ps) = 1307 
   
! -- The router outputs a Stat PDU N(PS) = 1307.
    
   *Jul 11 16:13:02.461: SSCOP(O - ATM2/0): 00 00 05 1B 00 00 00 1E 0B 00 00 00 
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): o Poll pdu, state = Active, n(s) = 0, n(ps) = 1308 
   *Jul 11 16:13:09.413: SSCOP(O - ATM2/0): 00 00 05 1C 0A 00 00 00 
  
 ! -- The router outputs a second Poll PDU after ~10sec N(PS) = 1308.
 
   *Jul 11 16:13:09.413: SSCOP(I - ATM2/0): 00 00 05 1C 00 00 00 1E 0B 00 00 00 
   
! -- The router receives a Stat PDU N(PS) = 1308.
    
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): i Stat pdu, Active state, length = 12 
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): Rcv Stat in Active State 
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): processStatPdu: ps 1308, nmr 30, nr 0 
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): processStatPdu: vtPa 1307, vps 1308    
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): processStatPdu: vta 0, vts 0 
   *Jul 11 16:13:09.413: SSCOP(ATM2/0): processStatPdu: listCount = 0 - normal    
   *Jul 11 16:13:11.797: SSCOP(O - ATM2/0): 00 00 05 1C 0A 00 00 00 
   *Jul 11 16:13:11.797: SSCOP(ATM2/0): * Poll pdu, ns = 0, nps = 1308    
   
! -- The router receives a Poll PDU ~10sec after the first N(PS) = 1308. The debug marks 
   ! -- this packet with an O indicating outbound even though it is an incoming Poll PDU. 

   *Jul 11 16:13:11.797: SSCOP(ATM2/0): o Stat pdu, n(r) = 0, n(mr) = 30, n(ps) = 1308 
   *Jul 11 16:13:11.797: SSCOP(O - ATM2/0): 00 00 05 1C 00 00 00 1E 0B 00 00 00 
   
! -- We output a Stat PDU N(PS) = 1308.

Understanding maaError Codes

A number of events causes errors to be reported by SSCOP. The associated error parameter contains the error code that describes the specific error condition. Enabling debug sscop error may display error codes listed in the following table.

Error Code

Error Condition

maaError-A

Receipt of unsolicited or inappropriate SD PDU

maaError-B

Receipt of unsolicited or inappropriate BGN PDU

maaError-C

Receipt of unsolicited or inappropriate BGAK PDU

maaError-D

Receipt of unsolicited or inappropriate BGREJ PDU

maaError-E

Receipt of unsolicited or inappropriate End PDU

maaError-F

Receipt of unsolicited or inappropriate EndAK PDU

maaError-G

Receipt of unsolicited or inappropriate Poll PDU

maaError-H

Receipt of unsolicited or inappropriate Stat PDU

maaError-I

Receipt of unsolicited or inappropriate UStat PDU

maaError-J

Receipt of unsolicited or inappropriate RS PDU

maaError-K

Receipt of unsolicited or inappropriate RSAK PDU

maaError-L

Receipt of unsolicited or inappropriate ER PDU

maaError-M

Receipt of unsolicited or inappropriate ERAK PDU

maaError-O

Unsuccessful retransmission VT(CC) >=MacCC

maaError-P

Unsuccessful retransmission Timer_NO_RESPONSE expriry

maaError-Q

SD or Poll, N(S) error

maaError-R

Stat N(PS) error

maaError-S

Stat N(R) or list elements error

maaError-T

UStat N(R) or list elements error

maaError-U

PDU length violation

maaError-V

SD Loss, SD PDUs must be retransmitted

maaError-W

Lack of Credit

maaError-X

Credit Obtained

maaError-P

This example shows an ATM switch running debug sscop error and losing SSCOP sessions because of a failure to receive Stat PDUs from the remote peer.

LS1010# debug sscop error atm12/1/2    
     *Jan 7 10:18:18.471 CST: SSCOP(12/1/2:0): SCP - no response timer expiry      
     *Jan 7 10:18:18.471 CST: SSCOP(12/1/2:0): Active : maaError-P 
     *Jan 7 10:18:18.471 CST: SSCOP(12/1/2:0): AAL-RELEASE-INDICATION      
     *Jan 7 10:18:18.471 CST: SSCOP(12/1/2:0): start T309 
     *Jan 7 10:18:18.471 CST: ATMSIG(12/1/2:0 0,175 - 1200336/00): 
     *Jan 7 10:18:18.471 CST: ATMSIG:atmSig_sscopFail: removing svc vpi 0 vci 175, 
     state Release Indication(N12) 
     *Jan 7 10:18:27.875 CST: SSCOP(12/1/2:0): INIT: initSscopCb 
     *Jan 7 10:18:27.875 CST: SSCOP(12/1/2:0): stop T309 
     *Jan 7 10:18:28.263 CST: SSCOP(12/1/2:0): Idle : maaError-H

SSCOP timers control operation of the the protocol. Expiration of the Timer_NO-RESPONSE timer results in an AAL-RELEASE-INDICATION message from SSCOP to ATM signaling. Signaling tries to re-establish the connection and start the T309 timer, which is ten seconds by default. Once the T309 timer expires, the SSCOP session is reinitialized, and the interface is cleared. In the following sample output of debug sscop error, the initScopCb message in the log indicates that the VCs were cleared.

*Jun 8 13:19:45.091: SSCOP(12/0/1:0): SCP - no response timer expiry 
   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): Active : maaError-P 
   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): AAL-RELEASE-INDICATION 
   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): start T309 
   *Jun 8 13:19:54.531: SSCOP(12/0/1:0): INIT: initSscopCb 
   *Jun 8 13:19:54.531: SSCOP(12/0/1:0): stop T309

Troubleshoot these error messages by checking for and eliminating the cause of any input errors or high CPU on either device. Use the sscop noresponse-timer <interface> command to change the Timer_No-Response value.

Note: Changing SSCOP timers from their default values can be lead to unexpected results and should be done only under the direction of a Cisco support engineer.

maaError-V

An maaError-V error message indicates that the ATM interface missed Sequenced Data PDUs and retransmission was required. SSCOP prints this message when it receives a retransmit request from the peer. If the error is seen often and is accompanied by terminated SSCOP sessions, investigate the cause of the messages.

The following log message indicates the same symptoms. No PDU with seqnum 14161 was received and retransmission was requested. Occasional retransmits are normal. Repeated retransmits can indicate a physical layer problem or cell drops on heavily utilized links.

ERROR: removeSdFromAckQ: no pak in RcvQ with seqnum 14161

maaError-R

This message indicates that the device has received a Stat PDU with a bad Poll Sequence Number. If a device sends a Poll PDU with Poll Sequence Number N(PS) and then receives a Stat with a different N(PS) value, the device receiving the Stat will report the an sscop_sequenceError and maaError-R if debug sscop error is enabled. The device receiving the bad sequence number resets the session and transmits a BGN PDU.

Troubleshoot this problem by enabling debug sscop event atm on both devices. Verify that the Poll PDU is sent with a different N(PS) value than the N(PS) value seen in the corresponding Stat PDU. The device that receives the Poll and responds with a Stat PDU with the incorrect N(PS) is suspect. Determine the frequency of the event and replace the suspect ATM hardware.

maaError-S

This message indicates the the device received a Stat PDU with a bad value for the Buffer Release Parameter N(R). In other words, the N(R) value returned in the Stat PDU tells the sender which SD PDUs were received correctly by the sender. Receiving a Stat PDU from the far-end with an N(R) value that the near-end has not yet sent leads to an maaError-S. Upon receiving the Stat PDU with the sequence error, the device resets the connection and transmits a BGN PDU.

Troubleshoot this problem by enabling debug sscop event on the receiving device. The device that sent the Stat PDU with an errored N(R) value is suspect. The problem may be the result of a software defect or faulty hardware.

Sample Output 1

The following output was captured from a Catalyst 8540 with a LANE client configured on the internal management interface, atm0. Interface ATM 2/0/3 is experiencing SSCOP resets. The commands debug sscop error atm2/0/3 and debug sscop event atm 2/0/3 were used to capture this output. Troubleshooting isolated the problem to a large number of cyclic redundancy check (CRC) errors caused by a physical-layer problem.

Jan 26 00:21:17.066: %LANE-5-UPDOWN: ATM0.149 elan test: LE Client changeds 
   tate to up 
   Jan 26 03:09:02.614: SSCOP(2/0/3:0): AAL-RELEASE-INDICATIONSscop state:    
   ActiveSscop Event: Rcv End 
   
! -- End PDU is received.
 
   Jan 26 03:09:02.614: SSCOP(2/0/3:0): start T309 
   Jan 26 03:09:02.614: SSCOP(2/0/3:0): stop T309 
   
! -- T309 timer is started and then immediately stopped when an End PDU is received. 

   Jan 26 03:09:02.614: SSCOP(2/0/3:0): AAL-ESTABLISH-INDICATION 
   Jan 26 03:09:03.586: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:04.570: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:05.546: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:06.542: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:06.658: %LANE-5-UPDOWN: ATM0.149 elan test: LE Client changeds 
   tate to downJan 26 03:09:07.518: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu,    retransmission, N(SQ) 2 
   Jan 26 03:09:08.490: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:09.466: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:10.442: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   Jan 26 03:09:11.426: SSCOP(2/0/3:0): SCPEVNT: incoming Begin pdu, retransmission, N(SQ) 2 
   
! -- The peer is repeatedly retransmiting Begin PDUs for 10 seconds.  
   ! -- We know that it is a retransmission because the N(SQ) is the same in each Begin PDU. 

   Jan 26 03:09:12.338: SSCOP(2/0/3:0): AAL-RELEASE-INDICATIONSscop state:       ActiveSscop Event: Rcv End 
   
! -- An End PDU finally is received when the T309 timer expires.
 
   Jan 26 03:09:12.338: SSCOP(2/0/3:0): start T309 
   Jan 26 03:09:21.650: SSCOP(2/0/3:0): INIT: initSscopCb 
   Jan 26 03:09:21.650: SSCOP(2/0/3:0): stop T309

Sample Output 2

The following output was captured from an ATM switch interface in one of the bottom five slots of a Catalyst 5500. The output is using the debug sscop error atm command on ATM 12/0/1.

*Jun 8 12:53:02.075: SSCOP(12/0/1:0): INIT: initSscopCb 
   *Jun 8 12:53:02.075: SSCOP(12/0/1:0): stop T309 
   *Jun 8 12:53:19.991: SSCOP(12/0/1:0): Active : maaError-V 
   *Jun 8 12:53:52.319: SSCOP(12/0/1:0): Active : maaError-V 
  
 ! -- maaError-V indicates a lost SD PDU.  
  
   *Jun 8 13:03:50.307: %ATMSSCOP-5-SSCOPINIT: - Intf : 12/0/1:0, Event :    
   Rcv End, State : Active. 
   *Jun 8 13:03:50.311: SSCOP(12/0/1:0): INIT: initSscopCb 
   *Jun 8 13:03:50.311: SSCOP(12/0/1:0): stop T309 
   *Jun 8 13:08:53.487: %ATMSSCOP-5-SSCOPINIT: - Intf : 12/0/1:0, Event :    
   Rcv End, State : Active. 
   *Jun 8 13:08:53.487: SSCOP(12/0/1:0): INIT: initSscopCb 
   *Jun 8 13:08:53.487: SSCOP(12/0/1:0): stop T309 
   *Jun 8 13:09:39.663: SSCOP(12/0/1:0): Outgoing Connection Pending :    
   maaError-O 
   *Jun 8 13:09:39.663: SSCOP(12/0/1:0): INIT: initSscopCb 
   *Jun 8 13:09:39.663: SSCOP(12/0/1:0): stop T309 
   *Jun 8 13:13:19.507: SSCOP(12/0/1:0): Active : maaError-V 
   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): SCP - no response timer expiry    
   
! -- The Timer_NO-RESPONSE expires because no Stat 
   ! -- PDU has been received from the peer for 45 seconds. 

   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): Active : maaError-P 
   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): AAL-RELEASE-INDICATION 
   *Jun 8 13:19:45.091: SSCOP(12/0/1:0): start T309 
   
! -- The T309 timer is started. After 10 seconds, the interface is cleared.
 
   *Jun 8 13:19:54.531: SSCOP(12/0/1:0): INIT: initSscopCb 
   *Jun 8 13:19:54.531: SSCOP(12/0/1:0): stop T309 
   *Jun 8 13:19:56.623: SSCOP(12/0/0:0): Active : maaError-V

High CPU Utilization

Under rare circumstances, SSCOP resets are caused by high CPU utilization of the router or switch. During periods of high CPU, you also may see incrementing input drops, throttles and other input errors in the output of show interface atm. These errors indicate the the ATM interface is receiving a large number of packets that are being process switched.

Process switching is an IOS switching method that takes care of all packets destined to the CPU. As a control packet, SSCOP packets must be seen and processed by the CPU. When the CPU is busy and running many processes, SSCOP Poll PDUs can be delayed in the input hold queue. An ATM switch may react to this delay and the failure to receive responses to Poll PDUs within a specified interval by resetting the SSCOP session.

The sscop quick-poll command was introduced to help eliminate SSCOP resets caused by high CPU utilization. SSCOP quick-poll gives preferential treatment to Poll PDUs currently waiting for processing in the input hold queue.

Note: This feature does not help eliminate disconnected sessions if the Poll PDUs are dropped and never make it to the input hold queue.

The sscop quick-poll command is enabled by default starting with the following Cisco IOS Software Releases:

  • Catalyst 5000 and 6000 ATM modules - Cisco IOS Software Release 11.3(2.5)WA4(4.10) and higher.

  • Routers and campus ATM switches - Cisco IOS Software Release 11.1.21, 11.121 CC, 11.1.21CA, 11.2.15, 11.2.15P, 12.0(1) and higher.

    Under rare circumstances, sscop quick-poll leads to SSCOP resets caused by the receipt of bad Poll sequence numbers. This problem is documented in Cisco bug ID CSCdk08643. Use the interface configuration command no sscop quick-poll to disable quick-polling on the interface.

Related Information

Updated: May 12, 2005 Document ID: 10504