navbarPDF Strip_TechNotes

Troubleshooting Switch Port and Interface Problems

Document ID: 12027

Contents

Introduction

This document is intended to help determine why a port or interface is experiencing problems. This document applies to Catalyst switches running CatOS Software on the Supervisor or Cisco IOS® System Software on the Supervisor.

Conventions

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

Prerequisites

Readers of this document should be knowledgeable of the following:

Components Used

The information in this document is based on the software and hardware versions below.

Physical Layer Troubleshooting

Using the LEDS to Troubleshoot

If you have physical access to the switch, it may save time to look at the port LEDs which give you the link status or may indicate an error condition (if red or orange).  The table below describes the LED status indicators for Ethernet modules or fixed-configuration switches:

Platform
 URL
Catalyst 6000 Series Switches
 Ethernet Module LEDs
Catalyst 5000 Series Switches
 Ethernet Module LEDs
Catalyst 4000 Series Switches
 Ethernet Module LEDs
Catalyst 3750 Series Switches
 Front Panel LEDs
Catalyst 3550 Series Switches
 Front Panel LEDs
Catalyst 2950/2955 Series Switches
 Front Panel LEDs
Catalyst 2900/3500XL Series Switches
 Front Panel LEDs
Catalyst 1900 and 2820 Series Switches
 Front Panel LEDs
Catalyst G-L3 Series Switches
 Front Panel LEDs

Ensure that both sides have a link. A single broken wire, or one port being shutdown, can cause the problem where one side has a link light, but the other side does not.

A link light does not guarantee that the cable is fully functional. The cable may have encountered physical stress that causes it to be functional at a marginal level. Normally you can identify this situation by the port having many packet errors, or the port constantly flapping (losing and regaining link).

Check the Cable and Both Sides of the Connection

If the link light for the port does not come on, you might consider the following possibilities:

Possible Cause Corrective Action
No cable connected Connect cable from switch to a known good device.
Wrong Port
 Make sure that both ends of the cable are plugged into the correct ports.
Device has no power Ensure that both devices have power.
Wrong cable type Verify the cable selection.  Refer to the  Catalyst Switch Cable Guide
Bad cable Swap suspect cable with known good cable. Look for broken or missing pins on connectors.
Loose connections
 Check for loose connections. Sometimes a cable appears to be seated in the jack, but is not.  Unplug the cable and reinsert it.
Patch Panels
 Eliminate faulty patch panel connections. Bypass the patch panel if possible to rule it out.
Media Convertors
 Eliminate faulty media convertors: fiber-to-copper, etc. Bypass the media convertor if possible to rule it out.
Bad or wrong Gigabit Interface Convertor (GBIC)
 Swap suspect GBIC with known good GBIC.

Verify Hw and Sw support for this type of GBIC. Refer to the Gigabit Ethernet Troubleshooting section of this document.
Bad Port or Module

Port or Interface or Module not enabled		 Move the cable to a known good port to troubleshoot a suspect port or module.

Use the show port command for CatOS or the show interface command for Cisco IOS to look for errdisable, disable or shutdown status.

The show module command may indicate faulty, which could indicate a hardware problem.  Refer to the Common Port and Interface Problems section of this document for more information.

Ethernet Copper and Fiber Cables

Make sure you have the correct cable for the type of connection you are making. Category 3 copper cable can be used for 10 Mbps unshielded twisted pair (UTP) connections, but should never be used for 10/100 or 10/100/1000Mbps UTP connections.  Always use either Category 5, Category 5e, or Category 6 UTP for 10/100 or 10/100/1000Mbps connections.

Caution   Category 5e and Category 6 cables can store high levels of static electricity because of the dielectric properties of the materials used in their construction. Always ground the cables (especially in new cable runs) to a suitable and safe earth ground before connecting them to the module.  

For fiber, make sure you have the correct cable for the distances involved and the type of fiber ports being used. The two options are singlemode fiber (SMF) or multimode fiber (MMF). Make sure the ports on the devices being connected together are both SMF, or both are MMF ports.

Note: For fiber connections, make sure the transmit lead of one port is connected to the receive lead of the other port. Connections for transmit-to-transmit and receive-to-receive will not work.

Ethernet and Fast Ethernet Maximum Transmission Distances

Transceiver Speed Cable Type Duplex Mode Maximum Distance Between Stations

10 Mbps

Category 3 UTP

Full and half

328 ft (100 m)

10 Mbps

MMF

Full and half

1.2 mi (2 km)

100 Mbps

Category 5 UTP
Category 5e UTP

Full and half

328 ft (100 m)

100 Mbps
 Category 6 UTP
 Full and half
 328 ft (100 m)

100 Mbps

MMF

Half

1312 ft (400 m)

 

 

Full

1.2 mi (2 km)

100 Mbps

SMF

Half

1312 ft (400 m)

 

 

Full

6.2 mi (10 km)


For more details on the different types of cables/connectors, cabling requirements, optical requirements (distance, type, patch cables, etc.), how to connect the different cables, and which cables are used by most Cisco switches and modules, refer to the following document:

Gigabit Ethernet Troubleshooting

If you have device A connected to device B over a Gigabit link, and the link does not come up, perform the following procedure.

Step-by-Step Procedure

  1. Verify device A and B are using the same GBIC, short wavelength (SX), long wavelength (LX), long haul (LH), extended wavelength (ZX), or copper UTP (TX). Both devices must use the same type of GBIC to establish link. An SX GBIC needs to connect with an SX GBIC. An SX GBIC will not link with an LX GBIC.  Refer the following document for more information: Mode-Conditioning Patch Cord Installation Note.
  1. Verify distance and cable used per GBIC as defined in the following table.

     1000BASE-T and 1000BASE-X Port Cabling Specifications

    GBIC Wavelength (nm) Copper/Fiber Type Core Size1 (Microns) Modal Bandwidth (MHz/km) Cable Distance2

    WS-G5483
    1000Base - T
    (copper)

    -

    Category 5 UTP

    Category 5e UTP
    Category 6 UTP

    -

    -

    328 ft (100 m)

    WS-G5484 1000BASE-SX3

    850

    MMF

     

    62.5

    62.5

    50.0

    50.0

    160

    200

    400

    500

    722 ft (220 m)

    902 ft (275 m)

    1640 ft (500 m)

    1804 ft (550 m)

    WS-G5486 1000BASE-LX/LH

    1310

    MMF4

     

     

    SMF

    62.5

    50.0

    50.0

    8.3/9/10

    500

    400

    500

    -

    1804 ft (550 m)

    1804 ft (550 m)

    1804 ft (550 m)

    6.2 miles (10 km)

    WS-G5487 1000BASE-ZX5

    1550

    SMF

    SMF6

    8.3/9/10

    8.3/9/10

    -

    -

    43.5 miles (70 km)7

    62.1 miles (100 km)


    1     The numbers given for multimode fiber-optic cable refer to the core diameter. For single-mode fiber-optic cable, 8.3 microns refers to the core diameter. The 9-micron and 10-micron values refer to the mode-field diameter (MFD), which is the diameter of the light-carrying portion of the fiber. This area consists of the fiber core plus a small portion of the surrounding cladding. The MFD is a function of the core diameter, the wavelength of the laser, and the refractive index difference between the core and the cladding.

    2 Distances are based on fiber loss. Multiple splices and substandard fiber-optic cable will reduce cabling distances.

    3 Use with MMF only.

    4 When using an LX/LH GBIC with 62.5-micron diameter MMF, you must install a mode-conditioning patch cord (CAB-GELX-625 or equivalent) between the GBIC and the MMF cable on both the transmit and receive ends of the link. The mode-conditioning patch cord is required for link distances less than 328 feet (100 m) or greater than 984 feet (300 m). The mode-conditioning patch cord prevents overdriving the receiver for short lengths of MMF and reduces differential mode delay for long lengths of MMF.  Refer the following document for more information: Mode-Conditioning Patch Cord Installation Note

    5 Use with SMF only.

    6 Dispersion-shifted single-mode fiber-optic cable.

    7 The minimum link distance for ZX GBICs is 6.2 miles (10 km) with an 8-dB attenuator installed at each end of the link. Without attenuators, the minimum link distance is 24.9 miles (40 km).

  1. If either device has multiple Gigabit ports, connect the ports to each other. This will test each device and verify that the Gigabit interface is functioning correctly. For example, you have a switch that has two Gigabit ports. Wire Gigabit port one to Gigabit port two. Does the link come up?  If so, the port is good. STP will block on the port and prevent any loops (port one receive (RX) goes to port two transmit (TX), and port one TX goes to port two RX).
  1. If single connection or Step 3 fails with SC connectors, loop the port back to itself (port one RX goes to port one TX). Does the port come up?  If not, contact the TAC, as this may be a faulty port.
  1. If steps 3 and 4 are successful, but a connection between device A and B cannot be established, loop ports with the cable adjoining the two devices. Verify that there is not a faulty cable.
  1. Verify that each device supports 802.3z specification for Gigabit auto-negotiation. Gigabit Ethernet has an auto-negotiation procedure that is more extensive than the one used for 10/100 Ethernet (Gigabit auto-negotiation spec: IEEE Std 802.3z-1998). When you enable link negotiation, the system auto-negotiates flow control, duplex mode, and remote fault information. You must either enable or disable link negotiation on both ends of the link. Both ends of the link must be set to the same value or the link cannot connect. Problems have been seen when connecting to devices manufactured before the IEEE 802.3z standard was ratified. If either device does not support Gigabit auto-negotiation, disabling Gigabit auto-negotiation will force the link up.

Warning: Disabling auto-negotiation hides link drops or physical layer problems. Disabling auto-negotiation is only required if end-devices such as older Gigabit NICs are used which may not support IEEE 802.3z.  Do not disable auto-negotiation between switches unless absolutely required to do so, as physical layer problems may go undetected, resulting in STP loops. The alternative is contacting the vendor for software/hardware upgrade for IEEE 802.3z Gigabit auto-negotiation support.

For troubleshooting the error message: %SYS-4-PORT_GBICBADEEPROM: / %SYS-4-PORT_GBICNOTSUPP, refer to:
 For GigabitEthernet system requirements as well as Gigabit Interface Converters (GBICs), Coarse Wavelength Division Multiplexing (CWDM), and Small Form-Factor Pluggable (SFP) system requirements, refer to:
For general configuration and troubleshooting information, refer to:

Connected Vs Notconnected

Most Cisco switches default to having a port in the notconnect state.  This means it is currently not connected to anything, but is willing to connect if it has a good connection to another operational device.  If you connect a good cable to two switch ports in the notconnect state, the link light should become green for both ports and the port status should indicate connected. This means the port is up as far as Layer 1 (L1) is concerned.

For CatOS, you can use the show port command to verify whether the port has a connected or notconnect status, or whether it is another state that would cause connectivity to fail, like disabled or errdisable.

Switch> (enable) sh port status 3/1
  Port  Name                 Status     Vlan       Duplex Speed Type
  ----- -------------------- ---------- ---------- ------ ----- ------------
   3/1                       disabled   1            auto  auto 10/100BaseTX
!--- The show port status {mod/port} command show the port is disabled.
!--- Use the set port enable {mod/port}command to try and re-enable it.

For Cisco IOS, you can use the show interfaces command to verify whether the interface is "up, line protocol is up (connected)". The first "up"  refers to the physical layer status of the interface.  The "line protocol up" message shows the data link layer status of the interface and   says that the interface can send and receive keepalives.

Router#show interfaces fastEthernet 6/1
FastEthernet6/1 is down, line protocol is down (notconnect)
!--- The interface is down and line protocol is down.
!--- Reasons: In this case,
!--- 1) A cable is not properly connected or not connected at all to this port.
!--- 2) The connected cable is faulty.
!--- 3) Other end of the cable is not connected to an active port or device.

!--- Note: For gigabit connections, GBICs need to be matched on each 
!--- side of the connection. 
!--- There are different types of GBICs, depending on the cable and 
!--- distances involved: short wavelength (SX), 
!--- long-wavelength/long-haul (LX/LH) and extended distance (ZX). 
!--- An SX GBIC needs to connect with an SX GBIC; 
!--- an SX GBIC does not link with an LX GBIC. Also, some gigabit 
!--- connections require conditioning cables, 
!--- depending on the lengths involved.


Router#show interfaces fastEthernet 6/1
FastEthernet6/1 is up, line protocol is down (notconnect)
!--- The interface is up (or not in a shutdown state), but line protocol down.
!--- Reason: In this case, the device on the other side of the wire is a 
!--- CatOS switch with its port disabled.

Router#sh interfaces fas 6/1 status
Port   Name    Status       Vlan    Duplex   Speed  Type
Fa6/1          notconnect    1       auto     auto   10/100BaseTX
!--- The show interfaces card-type [slot/port] status command is the equivalent
!--- of show port status for CatOS.
If show port shows connected or show interfaces shows up/ line protocol up (connected) but you see errors incrementing in the output of either command, refer to the Understanding Specfic Port and Interface Counter Output for CatOS or Cisco IOS or Common Port and Interface Problems sections of this document for troubleshooting advice.

Most Common Port and Interface Troubleshooting Commands for CatOS and Cisco IOS

The table below shows the most common commands used for troubleshooting port or interface problems on switches running CatOS Software on the Supervisor or Cisco IOS System Software on the Supervisor.

Note: Select a command in the left hand column to go to documentation for that command.  The right hand column gives a brief description of what the command does and lists any exceptions to it's use per platform.

The following commands are supported by the Output Interpreter tool for CatOS and can be used to assist in troubleshooting switch port or problems: show version, show module, show port, show counters, or show mac.

If you have the output of the supported commands from your Cisco device, you can use to display potential issues and fixes. To use Output Interpreter, you must be a registered user, be logged in, and have JavaScript enabled.

CatOS Commands

 Cisco IOS Commands
 Description
show version show version
 For switches running CatOS, this command displays software and hardware version info per module and system memory sizes.

For switches running Cisco IOS, this command displays output similar to a Cisco router, like software image name and version information and system memory sizes.

Helpful in searching for software/hardware incompatibilities (using the Release Notes or Software Advisor) and bugs (using the Software Bug Toolkit)

For more information on using show version command, refer to the Software Problems section of this document
show module show module

For Catalyst 6000, 5000, 4000 and other modular switches running CatOS or Cisco IOS, this command displays what cards are present in the switch, the version of software they are running, and what state the modules are in: ok, faulty, etc.

Helpful in diagnosing a hardware problem on a module or port.

For more information on troubleshooting hardware problems using the show module command, see the Port or Interface Status is disable or shutdown or the Hardware Problems section of this document.
show config show running-config
 For CatOS, this command displays the non-default configuration settings of the switch (all changes made to the default configuration).  All changes to the config in CatOS are saved automatically.

For Cisco IOS, this command displays the current configuration file of the switch.  Changes are saved to the config in Cisco IOS using the write memory command.

Helpful in determining whether a misconfiguration of the mod/port or interface, may be causing a problem.
show port show interfaces
 For CatOS, the show port command displays whether the port is connected, what VLAN it is in, what speed/duplex it is running at, channel information, errors, etc.

For Cisco IOS, the show interfaces command displays the administrative and operational status of a switching port, input and output packets, buffer failures, errors, etc.

The output of these two commands is discussed in more detail in the Understanding Port and Interface Counter Output for CatOS and Cisco IOS section of this document.
clear counters
 clear counters
 For CatOS and Cisco IOS use the clear counters command to zero the traffic and error counters so that you can see if the problem is only temporary, or if the counters continue to increment.
show port counters
 show interfaces counters
For CatOS, the show port <mod/port> command displays port error counters like FCS, alignments, collisions, etc.

For Cisco IOS on the Catalyst 6000, 4000, 3550, 2950, and and 3750 series, the equivalent command is show interfaces  card-type x/y counters errors.

The output of these two commands is discussed in more detail in the Understanding Port and Interface Counter Output for CatOS and Cisco IOS section of this document.
show counters show counters interface

show controllers ethernet-controller
 For CatOS, the show counters command displays the 64-bit and 32-bit hardware counters for a given mod/port or interface.  Counters will vary depending on the module type and platform.

For Cisco IOS, the show counters interface command was introduced in software version 12.1(13)E for the Catalyst 6000 series only and is the equivalent of the show counters command for CatOS which displays 32-bit and 64-bit error counters.

For Cisco IOS on 2900/3500XL, 2950/2955, 3550, 2970 and 3750 series switches, the show controllers Ethernet-controller command is similar to the show counters command on CatOS platforms. Displays discarded frames, deferred frames, alignment errors, collisions, etc.
show mac show interfaces counters

 For CatOS, the show mac command displays the MAC counters for traffic passing through each port such as, received frames, transmit frames, out-lost, in-lost, etc. (This command does not list the MAC addresses learned on a port by the bridging software. Use the command show cam dynamic for that information.)

For Cisco IOS, the show interfaces card-type x/y counters command is similar to show mac for CatOS platforms.

The output of these two commands is discussed in more detail in the Understanding Port and Interface Counter Output for CatOS and Cisco IOS section of this document.
show test show diagnostic(s)

show post
 For CatOS, the show test command displays any hardware errors encountered on startup.

For Cisco IOS, the equivalent command is show diagnostic which was introduced in 12.1(11b)E for the Catalyst 6000 series and show diagnostics(with an s) which was introduced in for the Catalyst 4000 Series. Both commands display Power-On Self Test (POST) results.

For Cisco IOS on the 2900/3500XL, 2950/2955, 3550, 2970 and 3750 series switches, the equivalent command is show post which displays the results of the switch POST.

For more information on troubleshooting hardware related errors on Catalyst switches, refer to the  Hardware Problems section of this document.



Understanding Specific Port and Interface Counter Output for CatOS and Cisco IOS

Most switches have some way to track the packets and errors occurring on a port or interface.  The common commands used to find this type of information are described in the Most Common Port and Interface Troubleshooting Commands for CatOS and Cisco IOS section of this document.

Excessive errors for certain counters usually indicate a problem. When operating at half-duplex setting, some data link errors incrementing in Frame Check Sequence (FCS), alignment, runts, and collision counters are normal. Generally, a one percent ratio of errors to total traffic is acceptable for half-duplex connections. If the ratio of errors to input packets is greater than two or three percent, performance degradation may be noticed.

In half-duplex environments, it is possible for both the switch and the connected device to sense the wire and transmit at exactly the same time and result in a collision. Collisions can cause runts, FCS, and alignment errors due to the frame not being completely copied to the wire, which results in fragmented frames.

When operating at full-duplex, errors in FCS, Cyclic Redundancy Checks (CRC), alignment, and runt counters should be minimal. If the link is operating at full-duplex, the collision counter is not active. If the FCS, CRC, alignment, or runt counters are incrementing, check for a duplex mismatch. Duplex mismatch is a situation where the switch is operating at full-duplex and the connected device is operating at half-duplex, or vice versa. The results of a duplex mismatch will be extremely slow performance, intermittent connectivity, and loss of connection. Other possible causes of data link errors at full-duplex are bad cables, faulty switch ports, or NIC software/hardware issues. Refer to the Common Port and Interface Problems section of this document for more information.

Show Port for CatOS and Show Interfaces for Cisco IOS

The show port {mod/port} command is used when running CatOS on the Supervisor.  An alternative to this command is the show port counters {mod/port} which only displays the port error counters.   Refer to Table 1 for explanations of the error counter output  or click on the counter hyperlinks below.
 
Switch> (enable) sh port counters 3/1
  
  Port  Align-Err  FCS-Err    Xmit-Err   Rcv-Err    UnderSize
 ----- ---------- ---------- ---------- ---------- ---------
  3/1           0          0          0          0         0
 
  Port  Single-Col Multi-Coll Late-Coll  Excess-Col Carri-Sen Runts     Giants
 ----- ---------- ---------- ---------- ---------- --------- --------- ---------
  3/1           0          0          0          0         0         0         0
The show interfaces card-type {slot/port} command is the equivalent command for Cisco IOS on the Supervisor.  An alternative to this command (for Catalyst 6000, 4000, 3550, 2970 2950/2955, and 3750 series switches) is the show interfaces  card-type {slot/port} counters errors command which only displays the interface error counters.

Note: For 2900/3500XL Series switches use the show interfaces card-type {slot/port} command with the show controllers Ethernet-controller command.
Router#sh interfaces fastEthernet 6/1
FastEthernet6/1 is up, line protocol is up (connected)
   Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
   MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation ARPA, loopback not set
   Full-duplex, 100Mb/s
   input flow-control is off, output flow-control is off
   ARP type: ARPA, ARP Timeout 04:00:00
   Last input 00:00:14, output 00:00:36, output hang never
   Last clearing of "show interface" counters never
   Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
   Queueing strategy: fifo
   Output queue :0/40 (size/max)
   5 minute input rate 0 bits/sec, 0 packets/sec
   5 minute output rate 0 bits/sec, 0 packets/sec

The show interfaces command output up to this point is explained below (in order) :

Router#sh interfaces fas 6/1 status
	
	Port    Name               Status       Vlan       Duplex  Speed Type
	Fa6/1                      connected    1          a-full  a-100 10/100BaseTX
	!--- Autonegotiation was used to achieve full-duplex and 100Mbps.

The rest of the show interfaces command displays error counter output which is similar or equivalent to CatOS error counter output. Refer to Table 1 for explanations of the error counter output or click on the counter hyperlink below.

!--- ...show interfaces command output continues.
     1117058 packets input, 78283238 bytes, 0 no buffer
      Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
      0 watchdog, 0 multicast, 0 pause input
      0 input packets with dribble condition detected
      285811 packets output, 27449284 bytes, 0 underruns
      0 output errors, 0 collisions, 2 interface resets
      0 babbles, 0 late collision, 0 deferred
      0 lost carrier, 0 no carrier
      0 output buffer failures, 0 output buffers swapped out

The show interfaces card-type {slot/port} counters errors command is the equivalent Cisco IOS command to show port counters
for CatOS.  Refer to Table 1 for explanations of the error counter output or click on the hyperlinks below.

Router#sh interfaces fastEthernet 6/1 counters errors
  
 Port        Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize OutDiscards
 Fa6/1               0          0          0          0         0           0
 
 Port      Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen     Runts    Giants
 Fa6/1              0         0         0          0         0         0         0

Table 1:
CatOS error counter output for show port or show port counters for the Catalyst 6000, 5000 and 4000 Series.
Cisco IOS error counter output for show interfaces or show interfaces card-type x/y counters errors for the Catalyst 6000 and 4000 Series.

Counters
(in alphabetical order)		 Description and Common Causes of Incrementing Error Counters 
Align-Err
Description: CatOS sh port and Cisco IOS sh interfaces counters errors.
Alignment errors are a count of the number of frames received that don't end with an even number of octets and have a bad Cyclic Redundancy Check (CRC).

Common Causes: These are usually the result of a duplex mismatch or a physical problem (such as cabling, a bad port, or a bad NIC). When the cable is first connected to the port, some of these errors may occur. Also, if there is a hub connected to the port, collisions between other devices on the hub may cause these errors.

Platform Exceptions: Alignment errors are not counted on the Catalyst 4000 Series Supervisor I (WS-X4012) or Supervisor II (WS-X4013).
 
babbles

 Description: Cisco IOS sh interfaces counter.
CatOS counter indicating that the transmit jabber timer expired. A jabber is a frame longer than 1518 octets (excluding framing bits, but including FCS octets), which does not end with an even number of octets (alignment error) or has a bad FCS error.
 
Carri-Sen

 Description: CatOS sh port and Cisco IOS sh interfaces counters errors.
The Carri-Sen (carrier sense) counter increments every time an Ethernet controller wants to send data on a half duplex connection. The controller senses the wire and checks if it is not busy before transmitting.

Common Causes: This is normal on an half duplex Ethernet segment.
 
collisions

 Descriptions: Cisco IOS sh interfaces counter. The number of times a collision occurred before the interface transmitted a frame to the media successfully.

Common Causes: Collisions are normal for interfaces configured as half duplex, but should not be seen on full duplex interfaces.  If collisions are increasing dramatically, this points to a highly utilized link or possibly a duplex mismatch with the attached device.
 
CRC

 Description: Cisco IOS sh interfaces counter.  This increments when the CRC generated by the originating LAN station or far-end device does not match the checksum calculated from the data received.

Common Causes: This usually indicates noise or transmission problems on the LAN interface or the LAN itself. A high number of CRCs is usually the result of collisions but can also indicate a physical issue (such as cabling, bad interface or NIC) or a duplex mismatch.
 
deferred

 Description: Cisco IOS sh interfaces counter.  The number of frames that have been transmitted successfully after waiting because the media was busy.

Common Causes: This is usually seen in half duplex environments where the carrier is already in use when trying to transmit a frame.
 
pause input

 Description: Cisco IOS show interfaces counter. An increment in pause input counter means that the connected device is requesting for a traffic pause when its receive buffer is almost full.

Common Causes: This counter is incremented for informational purposes, since the switch accepts the frame. The pause packets stop when the connected device is able to receive the traffic.
 
input packets
with dribble condition

 Description: Cisco IOS sh interfaces counter.
A dribble bit error indicates that a frame is slightly too long.

Common Causes: This frame error counter is incremented for informational purposes, since the switch accepts the frame.
 
Excess-Col

 Description: CatOS sh port and Cisco IOS sh interfaces counters errors.
A count of frames for which transmission on a particular interface fails due to excessive collisions. An excessive collision happens when a packet has a collision 16 times in a row. The packet is then dropped

Common Causes: Excessive collisions are typically an indication that the load on the segment needs to be split across multiple segments but can also point to a duplex mismatch with the attached device. Collisions should not be seen on interfaces configured as full duplex.
 
FCS-Err
 Description: CatOS sh port and Cisco IOS sh interfaces counters errors.
The number of valid size frames with Frame Check Sequence (FCS) errors but no framing errors.

Common Causes:This is typically a physical issue (such as cabling, a bad port, or a bad Network Interface Card (NIC)) but can also indicate a duplex mismatch.
frame
 Description: Cisco IOS sh interfaces counter.
The number of packets received incorrectly having a CRC error and a non-integer number of octets (alignment error).

Common Causes: This is usually the result of collisions or a physical problem (such as cabling, bad port or NIC) but can also indicate a duplex mismatch.
 
Giants

 Description: CatOS sh port and Cisco IOS sh interfaces and sh interfaces counters errors.
Frames received that exceed the maximum IEEE 802.3 frame size (1518 bytes for non-jumbo Ethernet) and have a bad Frame Check Sequence (FCS).

Common Causes: In many cases, this is the result of a bad NIC.  Try to find the offending device and remove it from the network.

Platform Exceptions:
Catalyst Cat4000 Series running Cisco IOS
Previous to software version 12.1(19)EW, the giants counter would increment for a frame > 1518bytes. After 12.1(19)EW, a giant in show interfaces increments only when a frame is received >1518bytes with a bad FCS.

 
ignored

 Description: Cisco IOS sh interfaces counter.
The number of received packets ignored by the interface because the interface hardware ran low on internal buffers.

Common Causes: Broadcast storms and bursts of noise can cause the ignored count to be increased.
 
Input errors

 Description: Cisco IOS sh interfaces counter.

Common Causes: This includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also cause the input errors count to be increased, and some datagrams may have more than one error. Therefore, this sum may not balance with the sum of enumerated input error counts.
 
Late-Col

 Description: CatOS sh port and Cisco IOS sh interfaces and sh interfaces counters errors.
The number of times a collision is detected on a particular interface late in the transmission process. For a 10 Mbit/s port this is later than 512 bit-times into the transmission of a packet. Five hundred and twelve bit-times corresponds to 51.2 microseconds on a 10 Mbit/s system.

Common Causes: This error can indicate a duplex mismatch among other things. For the duplex mismatch scenario, the late collision is seen on the half duplex side. As the half duplex side is transmitting, the full duplex side does not wait its turn and transmits simultaneously causing a late collision. Late collisions can also indicate an Ethernet cable or segment that is too long. Collisions should not be seen on interfaces configured as full duplex.
 
lost carrier
 Description: Cisco IOS sh interfaces counter.
The number of times the carrier was lost during transmission.

Common Causes: Check for a bad cable.  Check the physical connection on both sides.
 
Multi-Col

Description: CatOS sh port and Cisco IOS sh interfaces counters errors.

The number of times multiple collisions occurred before the interface transmitted a frame to the media successfully.

Common Causes: Collisions are normal for interfaces configured as half duplex but should not be seen on full duplex interfaces. If collisions are increasing dramatically, this points to a highly utilized link or possibly a duplex mismatch with the attached device.

 
no buffer

 Description: Cisco IOS sh interfaces counter.
The number of received packets discarded because there is no buffer space.

Common Causes: Compare with ignored count. Broadcast storms can often be responsible for these events.
 
no carrier

 Description: Cisco IOS sh interfaces counter.
The number of times the carrier was not present during the transmission.

Common Causes: Check for a bad cable.  Check the physical connection on both sides.
Out-Discard
 Description: The number of outbound packets chosen to be discarded even though no errors have been detected.

Common Causes: One possible reason for discarding such a packet could be to free up buffer space.
 
output buffer failures
output buffers swapped out

Description: Cisco IOS sh interfaces counter.
The number of failed buffers and the number of buffers swapped out.

Common Causes:

A port will buffer the packets to the Tx buffer when the rate of traffic switched to the port is high and it cannot handle the amount of traffic. The port starts to drop the packets when the Tx buffer is full and thus increasing the underruns and the output buffer failure counters. The increase in the output buffer failure counters could be a sign that the ports are running at an inferior speed and/or duplex, or there is too much traffic going through the port.

As an example, consider a scenario where a 1gig multicast stream is being forwarded to 24 100 Mbps ports.  If an egress interface is over-subscribed, it would be normal to see output buffer failures incrementing along with Out-Discards.

For troubleshooting information, refer to the
Deferred Frames (Out-Lost or Out-Discard) section of this document.

 
output errors

 Description:Cisco IOS sh interfaces counter.
The sum of all errors that prevented the final transmission of datagrams out of the interface.
 
overrun

 Description: The number of times the receiver hardware was unable to hand received data to a hardware buffer.

Common Cause: The input rate of traffic exceeded the receiver's ability to handle the data.
packets input/output

Description: Cisco IOS sh interfaces counter. The total error free packets received and transmitted on the interface. Monitoring these counters for increments is useful in determining whether traffic is flowing properly through the interface. The bytes counter includes both the data and MAC encapsulation in the error free packets received and transmitted by the system. 

Rcv-Err

 Description: CatOS show port or show port counters and Cisco IOS (for the Catalyst 6000 Series only) sh interfaces counters error

Common Causes:  See Platform Exceptions below.

Platform Exceptions:
Catalyst 5000 Series
rcv-err = receive buffer failures. So for example, a runt or giant or an FCS-Err will not increment the rcv-err counter. The rcv-err counter on a 5K will only increment as a result of excessive traffic.

On Catalyst 4000 Series
rcv-err = the sum of all receive errors, which means, in contrast to the Catalyst 5000, that the rcv-err counter will increment when the interface receives an error like a runt, giant or FCS-Err.

 
Runts

 Description: CatOS sh port and Cisco IOS sh interfaces and sh interfaces counters errors
The frames received that are smaller than the minimum IEEE 802.3 frame size (64 bytes for Ethernet), and with a bad CRC.

Common Causes: This can be caused by a duplex mismatch and physical problems, such as a bad cable, port, or NIC on the attached device.

Platform Exceptions:
Catalyst 4000 Series running Cisco IOS
Previous to sw version 12.1(19)EW, a runt = undersize.
Undersize = frame < 64bytes.  The runt counter would only increment when a frame less than 64 bytes was received.  After 12.1(19EW, a runt = a fragment.  A fragment is a frame < 64 bytes but with a bad CRC.   The result is the runt counter now increments in show interfaces, along with the fragments counter in show interfaces counters errors when a frame <64 bytes with a bad CRC is received.
 
Single-Col

Description: CatOS sh port and Cisco IOS sh interfaces counters errors.

The number of times one collision occurred before the interface transmitted a frame to the media successfully.

Common Causes: Collisions are normal for interfaces configured as half duplex but should not be seen on full duplex interfaces. If collisions are increasing dramatically, this points to a highly utilized link or possibly a duplex mismatch with the attached device.

 
underruns

 Description: The number of times that the transmitter has been running faster than the switch can handle.

Common Causes: This can occur in a high throughput situation where an interface is being hit with a high volume of bursty traffic from many other interfaces all at once.  Interface resets may be occurring along with the underruns.
Undersize

Description: CatOS sh port and Cisco IOS sh interfaces counters errors

The frames received that are smaller than the minimum IEEE 802.3 frame size of 64 bytes (excluding framing bits, but including FCS octets) that are otherwise well formed.

Common Causes: Check the device sending out these frames.

 
Xmit-Err

Description: CatOS sh port and Cisco IOS sh interfaces counters errors

This is an indication that the internal send (Tx) buffer is full.

Common Causes:  A common cause of Xmit-Err might be traffic from a high bandwidth link being switched to a lower bandwidth link, or traffic from multiple inbound links being switched to a single outbound link. For example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a 100Mbps interface, this might cause Xmit-Err to increment on the 100Mbps interface. This is because the interface’s output buffer is overwhelmed by the excess traffic due to the speed mismatch between the incoming and outgoing bandwidths.

Show Mac for CatOS and Show Interfaces Counters for Cisco IOS

The show mac {mod/port}command is useful when running CatOS on the supervisor for monitoring inbound and outbound traffic on the port as displayed by the receive (Rcv) and transmit (Xmit) counters for unicast, multicast, and broadcast traffic. The output below is from a Catalyst 6000 running CatOS: 
Console> (enable) sh mac 3/1
  
  Port     Rcv-Unicast          Rcv-Multicast        Rcv-Broadcast
  -------- -------------------- -------------------- --------------------
   3/1                      177               256272                 3694
  
  Port     Xmit-Unicast         Xmit-Multicast       Xmit-Broadcast
  -------- -------------------- -------------------- --------------------
   3/1                       30               680377                  153
  
  Port     Rcv-Octet            Xmit-Octet
  -------- -------------------- --------------------
   3/1                 22303565             48381168
  
  MAC      Dely-Exced MTU-Exced  In-Discard Out-Discard
  -------- ---------- ---------- ---------- -----------
   3/1              0          0     233043          17
  
  Port  Last-Time-Cleared
  ----- --------------------------
   3/1  Sun Jun 1 2003, 12:22:47
This command also has the following error counters: Dely-Exced, MTU-Exced, In-Discard and Out-Discard.

Catalyst 4000 and 5000 series switches running CatOS have two additional error counters in the show mac command.  These are the In-Lost and Out-Lost counters:

MAC      Dely-Exced MTU-Exced  In-Discard Lrn-Discrd In-Lost    Out-Lost
-------- ---------- ---------- ---------- ---------- ---------- ----------
 5/1              0          0          0          0          0          0

The show interfaces card-type {slot/port} counters command is used when running Cisco IOS on the Supervisor.

Note: There are no equivalent counters to the CatOS show mac error counters: Dely-Exced, MTU-Exced and In-Discard in this command   There is, however, an Out-Discard counter in the Cisco IOS  show interfaces counters errors command which is explained in Table 1 above.
Router#sh interfaces fas 6/1 counters
  
  Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
  Fa6/1           47856076            23        673028           149
  
  Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
  Fa6/1           22103793            17        255877          3280
  Router#
  !--- Cisco IOS counters used to monitor inbound and outbound unicast, multicast
  !--- and broadcast packets on the interface.

Show Counters for CatOS and Show Counters Interface for Cisco IOS

The show counters [mod/port] command offers even more detailed statistics for ports and interfaces.  This command is available for CatOS and the equivalent show counters interface card-type {slot/port} command was introduced in Cisco IOS software version 12.1(13)E for the Catalyst 6000 series only.  These commands display the 32-bit and 64-bit error counters per port or interface.  Refer to the CatOS command documentation for show counters for more information.

Note: Counter stats for Catalyst 6000 series switches running Cisco IOS are in Hex.
Console> (enable) sh counters 3/1
  64 bit counters
  0  rxHCTotalPkts                      =               260555
  1  txHCTotalPkts                      =               687411
  2  rxHCUnicastPkts                    =                  177
  3  txHCUnicastPkts                    =                   30
  4  rxHCMulticastPkts                  =               256684
  5  txHCMulticastPkts                  =               687228
  6  rxHCBroadcastPkts                  =                 3694
  7  txHCBroadcastPkts                  =                  153
  8  rxHCOctets                         =             22386167
  9  txHCOctets                         =             48850817
  10 rxTxHCPkts64Octets                 =               228929
  11 rxTxHCPkts65to127Octets            =               701493
  12 rxTxHCPkts128to255Octets           =                  285
  13 rxTxHCPkts256to511Octets           =                17090
  14 rxTxHCpkts512to1023Octets          =                  168
  15 rxTxHCpkts1024to1518Octets         =                    1
  16 txHCTrunkFrames                    =               395217
  17 rxHCTrunkFrames                    =               236459
  18 rxHCDropEvents                     =                    0
  32 bit counters
  0  rxCRCAlignErrors                   =          0
  1  rxUndersizedPkts                   =          0
  2  rxOversizedPkts                    =          0
  3  rxFragmentPkts                     =          0
  4  rxJabbers                          =          0
  5  txCollisions                       =          0
  6  ifInErrors                         =          0
  7  ifOutErrors                        =          0
  8  ifInDiscards                       =     233043
  9  ifInUnknownProtos                  =          2
  10 ifOutDiscards                      =         17
  !--- Output suppressed.

Show Controller Ethernet-Controller for Cisco IOS

For Catalyst 3750, 3550, 2970, 2950/2955, 2940 and 2900/3500XL switches use the command show controller ethernet-controller to display traffic counter and error counter output that is similar to the sh port, sh interface, sh mac and show counters output for Catalyst 6000, 5000 and 4000 series switches.
3550-1#sh controller ethernet-controller fastEthernet 0/1
  !--- Output from a Catalyst 3550.
  
    Transmit FastEthernet0/1           Receive
          0 Bytes                        0 Bytes
          0 Unicast frames               0 Unicast frames
          0 Multicast frames             0 Multicast frames
          0 Broadcast frames             0 Broadcast frames
          0 Discarded frames             0 No dest, unicast
          0 Too old frames               0 No dest, multicast
          0 Deferred frames              0 No dest, broadcast
          0  1 collision frames
          0  2 collision frames          0 FCS errors
          0  3 collision frames          0 Oversize frames
          0  4 collision frames          0 Undersize frames
          0  5 collision frames          0 Collision fragments
          0  6 collision frames
          0  7 collision frames          0 Minimum size frames
          0  8 collision frames          0 65 to 127 byte frames
          0  9 collision frames          0 128 to 255 byte frames
          0 10 collision frames          0 256 to 511 byte frames
          0 11 collision frames          0 512 to 1023 byte frames
          0 12 collision frames          0 1024 to 1518 byte frames
          0 13 collision frames
          0 14 collision frames          0 Flooded frames
          0 15 collision frames          0 Overrun frames
          0 Excessive collisions         0 VLAN filtered frames
          0 Late collisions              0 Source routed frames
          0 Good (1 coll) frames         0 Valid oversize frames
          0 Good(>1 coll) frames         0 Pause frames
          0 Pause frames                 0 Symbol error frames
          0 VLAN discard frames          0 Invalid frames, too large
          0 Excess defer frames          0 Valid frames, too large
          0 Too large frames             0 Invalid frames, too small
          0 64 byte frames               0 Valid frames, too small
          0 127 byte frames
          0 255 byte frames
          0 511 byte frames
          0 1023 byte frames
          0 1518 byte frames
 
 3550-1#
 !--- See table below for additional counter output for 2900/3500XL Series switches.
Counter Description Possible Causes
Transmitted Frames 
Discarded frames
The total number of frames whose transmission attempt is abandoned due to insufficient resources. This total includes frames of all destination types. The traffic load on the interface is excessive and is causing the frames to be discarded. Reduce the traffic load on the interface if you are seeing an increasing number of packets in this field. 
Too old frames
 Number of frames that took longer than two seconds to travel through the switch. For this reason, they were discarded by the switch. This would only happen under extreme, high stress conditions.
 The traffic load for this switch is excessive and is causing the frames to be discarded. Reduce the switch load if you are seeing an increasing number of packets in this field. You may need to modify your network topology to reduce the traffic load for this switch. 
Deferred
frames
 The total number of frames whose first transmission attempt was delayed, due to traffic on the network media. This total includes only those frames that are subsequently transmitted without error and without experiencing a collision. The traffic load destined for this switch is excessive and is causing the frames to be discarded. Reduce the switch load if you are seeing an increasing number of packets in this field. You may need to modify your network topology to reduce the traffic load for this switch. 
collision
frames
 The collision frames counters are the number of times a packet was attempted to be transmitted but was not successful, but was successful on its next attempt.  This means that if the 2 collision frames counter incremented, the switch attempted to send the packet twice and failed but was successful on its third attempt. The traffic load on the interface is excessive and is causing the frames to be discarded. Reduce the traffic load on the interface if you are seeing an increasing number of packets in these fields. 
Excessive
collisions
 The excessive collisions counter increases after 16 consecutive late collisions have occurred in a row. After 16 attempts have been made to send the packet the packet will be dropped and the counter will increment. If this counter is incrementing it is an indication of a wiring problem, an excessively loaded network, or a duplex mismatch. An excessively loaded network could be due to having to many devices on a shared Ethernet. 
Late
collisions
 A late collision occurs when two devices transmit at the same time, and neither side of the connection detects a collision. The reason for this occurrence is because the time to propagate the signal from one end of the network to another is longer than the time to put the entire packet on the network. The two devices that cause the late collision never see that the other is sending until after it puts the entire packet on the network. Late collisions are not detected by the transmitter until after the first 64 byte slot time. This is because they are only detected during transmissions of packets longer than 64 bytes. Late collisions are a result of incorrect cabling or a non-compliant number of hubs in the network. Bad NICs can also cause late collisions. 
Good (1 coll)
frames

 The total number of frames which experience exactly one collision and are then successfully transmitted.
 Collisions in a half-duplex environment are normal expected behavior.  
 
Good(>1 coll)
frames
 The total number of frames which experience between 2 and 15 collisions, inclusive, and are then successfully transmitted.
 Collisions in a half-duplex environment are normal expected behavior. Frames incrementing at the upper end of this counter run the risk of exceeding 15 collisions and being counted as Excessive collisions.
 
VLAN discard
frames

 The number of frames dropped on an interface because the CFI bit is set.
 The Canonical Format Indicator (CFI) bit in the TCI of an 802.1q frame is is set to 0 for the ethernet canonical frame format. If the CFI bit is set to 1, this indicates the presence of a RIF (Routing Information Field) or Token Ring noncanonical frame which is discarded.
Received Frames 
No bandwidth
frames
 2900/3500XL only.  The number of times that a port received a packet from the network, but the switch did not have the resources to receive it. This would only happen under stress conditions, but could happen with bursts of traffic on several ports. So, a small number of No bandwidth frames is not a cause for concern. (It still should be far less than one percent of the frames received.) The traffic load on the interface is excessive and is causing the frames to be discarded. Reduce the traffic load on the interface if you are seeing an increasing number of packets in this field.
 
No buffers
frames
 2900/3500XL only.  The number of times that a port received a packet from the network, but the switch did not have the resources to receive it. This would only happen under stress conditions, but could happen with bursts of traffic on several ports. So, a small number of No buffers frames is not a cause for concern. (It still should be far less than one percent of the frames received.) The traffic load on the interface is excessive and is causing the frames to be discarded. Reduce the traffic load on the interface if you are seeing an increasing number of packets in this field. 
No dest,
unicast

No destination unicast are the number of unicast packets that the port did not forward to any other ports.

The following are brief descriptions of when the No dest, (unicast, multicast, and broadcast) counters may increment:
  • If a port is an access port, and the port is connected to an Inter-Switch Link Protocol (ISL) trunk port, the No dest counter will be very large, as all incoming ISL packets will not be forwarded. This is an invalid configuration.
  • If a port is blocked by Spanning Tree Protocol (STP), most packets will not be forwarded, resulting in No dest packets.
  • If a port just acquired a link, there will be a very brief (less than one second) period where incoming packets are not forwarded.
  • If the port is in a VLAN by itself, and no other ports on the switch belong to that VLAN, all incoming packets will be dropped and the counter will increment.
  • The counter also increments when the destination address of the packet is learned on the port that the packet was received on. If a packet was received on port 0/1, with destination MAC address X, and the switch has already learned that MAC address X resides on port 0/1, it will increment the counter and discard the packet. This could happen in the following situations:
    • If a hub is connected to port 0/1, and a workstation connected to the hub transmits a packets to another workstation connected to the hub, port 0/1 will not forward this packet anywhere because the destination MAC resides on the same port.
    • This can also occur if a switch is connected to port 0/1, and starts flooding packets to all of its ports to learn MAC addresses.
  • If a static address has been set up on another port in the same VLAN, and no static address was set up for the receiving port, the packet will be dropped. For example, if a static map for MAC address X was configured on port 0/2 to forward traffic to port 0/3, the packet must be received on port 0/2 otherwise the packet will be dropped. If a packet is sent from any other port, in the same VLAN as port 0/2, the packet will be dropped.
  • If the port is a secure port, packets with disallowed source MAC addresses will not be forwarded and increment the counter.
 
No dest,
multicast
 No destination multicast are the number of multicast packets that the port did not forward to any other ports. 
No dest,
broadcast

No destination broadcast are the number of broadcast packets that the port did not forward to any other ports. 

Alignment
errors
 Alignment errors are the number of frames received that do not end with an even number of octets and have a bad CRC. Alignment errors are due to the frame not being completely copied to the wire, which results in fragmented frames. Alignment errors are the result of collisions at half-duplex, a duplex mismatch, bad hardware (NIC, cable, or port), or connected device generating frames that do not end with an octet and have a bad FCS. 
FCS errors
 FCS error count is the number of frames that were received with a bad checksum (CRC value) in the Ethernet frame. These frames are dropped and not propagated onto other ports. FCS errors are the result of collisions at half-duplex, a duplex mismatch, bad hardware (NIC, cable, or port), or a connected device generating frames with bad FCS. 
Undersize
frames

 These are the total number of packets received that were less than 64 octets long (excluding framing bits, but including FCS) and have a good FCS value.
This is an indication of a bad frame generated by the connected device. Verify that the connected device is operating correctly.
 
Oversize
frames

 Number of packets received by the port from the network, where the packets were more than 1514 bytes.
 This may be an indication of faulty hardware, dot1q or ISL trunking configuration issues.
 
Collision
fragments
 The total number of frames whose length is less than 64 octets (excluding framing bits, but including FCS) and have a bad FCS value. If this counter is incrementing, this is an indication that the ports are configured at half-duplex. Change the duplex setting to full-duplex. 
Overrun frames

 The number of times the receiver hardware was unable to hand received data to a hardware buffer.
 The input rate of traffic exceeded the receiver's ability to handle the data.
 
VLAN filtered
frames

 The total number of frames which are filtered because
of the type of VLAN information contained in the frame.
 The port may be configured to filter 802.1Q tagged frames. When a frame is received which contains an 802.1Q tag the frame is filtered and this statistic is incremented. 
Source routed
frames

 The total number of receive frames that are discarded due to the source route bit being set in the source address of the native frame.
 This kind of source routing is only defined for Token Ring and FDDI.  The IEEE ethernet specification forbids this bit to be set in any Ethernet frame.  Therefore, the switch discards such frames.
 
Valid oversize
frames

 The total number of frames received whose length exceeds the System MTU yet which have good FCS
values.
 This statistic counts frames that exceed the configured System MTU but which may have been increased from 1518 bytes to allow for Q-in-Q or MPLS encapsulations.
 
Symbol error
frames

 Gigabit Ethernet (1000 Base-X) uses 8B/10B Encoding to translate 8bit data from the MAC sublayer(layer 2) to a 10bit Symbol for sending over the wire.  When a port receives a Symbol, it extracts the 8 bit data from the  Symbol (10 bits). 

      		
      
    A Symbol error means the interface detects an undefined(invalid) 
      Symbol received.  Small amounts of symbol errors can be ignored. Large 
      amounts of symbol errors could could indicate a bad device, cable or bad 
      hardware.

      		
    

    

      
      
Invalid frames,
too large

      

      		
      Giant frames or frames received that exceed the maximum
IEEE 802.3        frame size   (1518   bytes for non-jumbo Ethernet) and
have a bad Frame Check        Sequence   (FCS).

      		
      In many cases, this is the result of a  bad NIC. 
  Try to find the offending device and remove it from the        network.

      		
    

    

      
      
Invalid frames,
too small

      

      		
      Runt frames or frames received that are less than
64 bytes (including the FCS bits and excluding the frame header) and have
either an FCS error or an alignment error.

      		
      This        can be caused by a duplex mismatch   
and physical problems, such as a bad        cable, port, or NIC on the attached
  device.

      		
    

   
  


     


Common System
Error Messages

        Cisco IOS sometimes has a different format for system messages. You may 
want to examine CatOS system messages and Cisco IOS system messages for a comparison. 
 You can do this by looking at the Messages and Recovery Procedures 
guide for the release of software you are running.  For example, you might 
look at  Messages 
and Recovery Procedures for CatOS software version 7.6 and compare them to 
the Messages 
and Recovery Procedures for Cisco IOS 12.1 E releases.

         


Error Messages on WS-X6348
    Modules

     Look at the following error messages:

         

     You may see syslog messages with one of the errors listed above appearing:

         

%SYS-5-SYS_LCPERR5:Module 9: Coil Pinnacle Header Checksum Error - Port #37

If you see this type of message or you notice that groups of  10/100 ports 
are failing on WS-X6348 modules, then refer to the following documents for further 
troubleshooting advice based on the operating system you are using:

              

         

              

%CDP-4-Duplex Mismatch

     The Cisco Discovery Protocol (CDP) is useful for detecting errors as well 
as port and system statistics on neighboring Cisco devices. CDP is Cisco proprietary 
and works be sending packets to a well-known mac address 01-00-0C-CC-CC-CC.

     

If you see a message like the following, you will have a duplex mismatch on one 
side of the connection:

           

%CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected on port 3/2

By default, Cisco switch ports and interfaces are set to autonegotiate.  You 
will need to match the speed and duplex settings on both sides by setting both 
sides to autonegotiate or by hardcoding.

     

     For more information on the causes of speed and duplex mismatches, refer 
  to the Speed/Duplex, 
  Autonegotiation, or NIC  Issues section of this document or these documents 
  for more information:

               

                               

         

%PAGP-5-PORTTO / FROMSTP and 
  %ETHC-5-PORTTO / FROMSTP

     For CatOS, use the show logging buffer command to view stored 
log   messages.  For Cisco IOS, use the show logging command.



  
Console> (enable) sh logging buffer
  2003 Jun 02 20:12:43 %PAGP-5-PORTTOSTP:Port 3/2 joined bridge port 3/2
  2003 Jun 02 20:59:56 %PAGP-5-PORTFROMSTP:Port 3/1 left bridge port 3/1
  !--- This is the command to view the logging buffer on switches running CatOS.



         This messages can cause concern for customers but  for the most
part   it is informational in nature.

                 

                 

The Port Aggregation Protocol (PAgP) negotiates Etherchannel links 
  between switches.  Whenever a device joins or leaves a bridge port, an 
  informational message is displayed on the console.  In most cases this 
  message is completely normal. However, if you see these messages on ports that 
  should not be flapping for any reason, then you should investigate further.

       

     In CatOS software version 7.x and later, "PAGP-5" was changed to "ETHC-5" 
  to make the message more understandable.

  

               This message is specific to the Catalyst 4000, 5000, and 6000
  series   switches running CatOS.  There are no error messa