Cisco IGX 8400 Series Switches

Frame Discards

Document ID: 10810

Updated: Oct 04, 2005



The dspchstats command displays of a set of statistics for a channel. These statistics indicate the number of frames successfully routed over the network and the number discarded on a specific connection (PVC).

This is the syntax of this command:

dspchstats \<channel> [interval]


<channel> is the channel for which statistics are to be displayed, and [interval] (optional) specifies in seconds the interval between updates of the display.

This document is intended to help determine the causes of frame discards.



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.


Refer to Cisco Technical Tips Conventions for more information on document conventions.

Frames Discarded "From Port, to Network" at Originating End

When frames are listed as discarded from port, to network at the originating end, discarded means that frames were received from the attached device, but not transmitted to the IPX network.

The dspportstats command shows the number of and reason for frame errors (discards) from the specified port. The dspportstats command shows port statistics for all connections to the specified port. Complete descriptions of frame errors are included in the manual.

  • Invalid CRC—The Frame Check Sequence (FCS) (also known as cyclic redundancy check [CRC]), calculated by the Frame Relay Port card (FRP), does not match the one sent with the frame.

  • Invalid Alignment—The frame is not an integral number of bytes in length.

  • Invalid Frame Length—The frame is less than 5 bytes or greater than 4,096 bytes in length.

    Note: The upper frame length limit varies depending upon the revision of FRP firmware, up to approximately 4,510 bytes.

  • Frame Format Error—The EA bits (the least significant bytes, or LSBs) of the address bytes are not "0 1", and the FRP did not interpret the first two bytes as a Data-Link Connection Identifiers (DLCI) address.

  • Unknown DLCI—The address received is not recognized by the FRP.

  • Last Unknown DLCI—A decimal recording of the last address received not recognized by FRP.

Frames Discarded "From Network, to Port" at Destination End

When frames are listed as discarded from network, to port at the destination end, discarded means that frames were received from the IPX network, but not transmitted to the attached device. Unlike discards From Port, no direct method exists for how to determine frame discards From Network. Therefore, the cause must be inferred from other sources.

Note: A remote loopback is a PVC loopback, and much of the FRP FRI circuitry is not tested. Further, frames are not incremented during a remote loopback. It is possible to have discards From Network and still pass a remote loopback.

  • Frames could be rejected from the originating port.

    Unless the frame is extremely small (entirely encapsulated within a single packet payload of 20 bytes), the frame requires more than one packet for transmission to the destination.

    When the frame is determined to be invalid after part of the frame has been transmitted, no additional frame data is transmitted. In later revisions of switch software, the frame is terminated by the transmission of a source abort packet. This packet informs the distant port interface card that the frame can be discarded in its entirety, and prevents the card from holding the partial frame awaiting reassembly.

    Local errors that show up as discards at the destination end are:

    • Invalid CRC at the originating end.

      If the CRC calculated by the originating port does not match the one sent in the frame, the IPX rejects the frame and does not send the last packet. The incomplete frame is then discarded at the destination end. Examine the statistics for the originating end with the dspportstats command.

    • Invalid alignment at the originating end.

      If the flag at the end of the frame does not occur on a byte boundary as measured by the originating port, the frame is rejected. Since no last packet is sent by the IPX in this condition, the partial frame is discarded at the destination end. Examine the statistics for the originating end with the dspportstats command.

    • Invalid frame length at the originating end.

      The frame length calculated by the originating port does not match the one sent with the frame. No last packet is sent, and the partial frame is discarded at the destination end. Examine the statistics for the originating end with the dspportstats command.

  • Frames can be damaged in transit.

    Even if frames are successfully received by the originating port, corruptions in the transmit path can cause the frame to be received in error at the destination end. In this case, the frame can be discarded before it is forwarded to the port. The transmission facilities in-route and common hardware, including the muxbus and trunk cards of all end-point and transit nodes, can be suspect.

    Possible reasons for damaged frames include:

    • The packets that make up the frame can be corrupted due to errors. If bit errors occur over the packet line, an invalid CRC is recorded at the destination end, and the frame is rejected. If this is the case, also expect other line impairments or errors to show in the dspplnerrs command output over the same route.

    • The packets that make up the frame can be dropped due to congestion. If bursty data packets drop when queued for transmission at originating or transit nodes, complete frames are not assembled at the destination end, which causes the frame to discard. View packet line errors to check for drops with the the dspplnerrs command for originating and any transit nodes. Drops can occur with high packet line utilization or poorly set AgeStep parameters in the cnfplnparms command output.

    • The packets that make up the frame could have arrived out of sequence. Although it is a rare case, a confused queuing algorithm can cause packets of the same frame to be queued in different subqueues. This results in the frames being rejected for a bad CRC.

    • Frames cannot exit destination port.

    If the tx port queue fills up and overflows, frames have no place to go and are discarded. A remote loopback can show that everything is good in this condition, as it is not routed through the tx port queue. To determine the current average level in the tx port queue, look at the Avg Q Depth in the far-right column of the dspportstats screen.

    Note: This queue is different from the Avg Q Depth on the Dspchstats screen, which is an input PVC queue. The default for the tx port queue is 65535 bytes.

    Note: The port queue can overflow because:

    • The port can be oversubscribed. Connections from several sources can exceed the speed capacity of the destination port. Issue the dspcons xx.x -f command to check the number and capacity of PVCs assigned to the port, and compare them to the port configuration.

    • The external receiving device can have a connection problem. If the external device is not connected, has bad cabling, or has a bad or missing clock, there can be connection problems. If the port is configured for DTE, the transmit clock must be provided by the external DCE device in order to clock out data from the port.

Note: "Measured Clock" is the receive clock, not the transmit clock in the dspfrport command output.

Related Information

Updated: Oct 04, 2005
Document ID: 10810