Frame Discards
Document ID: 10810
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Frames Discarded "From Port, to Network" at Originating End
Frames Discarded "From Network, to Port" at Destination End
Related Information
Introduction
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]
where:
<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.
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
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 CRCThe 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 AlignmentThe frame is not an integral number of bytes in length.
• Invalid Frame LengthThe 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 ErrorThe 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 DLCIThe address received is not recognized by the FRP.
• Last Unknown DLCIA 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
• Trickling Egress Frame Discards and PIF Overflows
• Why Frames and Bytes Are Discarded
• Cisco WAN Switching Solutions − Cisco Documentation
• Guide to New Names and Colors for WAN Switching Products
• Downloads − WAN Switching Software ( registered customers only)
• Technical Support & Documentation − Cisco Systems
Contacts & Feedback | Help | Site Map
© 2014 − 2015 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.
Updated: Oct 04, 2005
Document ID: 10810