Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Troubleshooting Common Issues on the Catalyst 2900XL and 3500XL Series Switches

Troubleshoot LEDs

In order to troubleshoot switches on the basis of LED information,       refer to the documentation on these devices:

Troubleshoot and Understand POST Failure Messages

Each time you power up the switch, eight Power-On Self Tests (POSTs)       run automatically. POSTs check the most important system components before the       switch begins to forward packets. When the switch begins the POST, the port       status LEDs display amber for two seconds, and then display green. As each test       runs, the port status LEDs go out. 1x is the first to go out. The port status       LEDs for ports 2x through 8x go out sequentially as the system completes a       test.

When the POST completes successfully, the port status LEDs go out. This       indicates that the switch is operational. If a test fails, the port status LED       associated with the test displays amber. The system LED also displays       amber.

Note: From Cisco IOS Software Release 11.2(8.5)SA6 onwards, the port and           system LEDs both remain amber after a POST failure. In the earlier Cisco IOS           Software Releases, only the LEDs of failed linked ports remained amber.

This table shows the LED and the component of the switch to which the       LED corresponds:

LED Components Tested
2xFlash memory
3xSwitch CPU
4xSystem board
5xCPU interface Application-Specific Integrated Circuit                     (ASIC)
6xSwitch core ASIC
7xEthernet controller ASIC
8xEthernet interfaces

At the time of the switch bootup sequence (cold start or through the       reload command), monitor the POST tests as they run       through a console connection to the switch. Here is an example:

   !--- Output is suppressed.  C2900 POST: System Board Test: Passed
  C2900 POST: CPU Buffer Test: Passed
  C2900 POST: CPU Notify RAM Test: Passed
  C2900 POST: CPU Interface Test: Passed
  C2900 POST: Testing Switch Core: Passed
  C2900 POST: Testing Buffer Table: Passed
  C2900 POST: Data Buffer Test: Passed
  C2900 POST: Configuring Switch Parameters: Passed
  C2900 POST: Ethernet Controller Test: Passed
  C2900 POST FAILURE: front-end post: FastEthernet0/2:
  C2900 POST FAILURE: looped-back packet not received
  C2900 POST FAILURE: front-end post: FastEthernet0/4:
  C2900 POST FAILURE: looped-back packet not received  C2900 POST: MII Test: Passed
  !--- Output is suppressed.

This output shows one example of a failure on a Catalyst 2900XL switch       at the time of the bootup sequence.

Alternatively, you can issue the show post command when the system runs, in order to see if any port had failed a POST       test. This command, available in Cisco IOS Software Release 11.2(8.5)SA6,       checks if the POST tests passed. If there is a failure, this command determines       which POST test failed. This command is useful when you are able to get a link       on a particular port, or the port LED is amber. For example, here is an output       from a Catalyst 2900XL which failed a POST test on FastEthernet interface       0/19:

2900XL# show postPOST FAILED: FastEthernet0/19 failed front-end loopback test

When there is no POST failure, you see this output. This output is       captured from a Catalyst 3500XL switch:

3512xl#show postPassed

See the Common Reasons and Solutions section for more information on POST failure messages.

Common Reasons and Solutions

A POST failure usually indicates physical damage to the interface. If       an Ethernet Controller that controls four interfaces fails, those ports fail       too. A common cause of such damage is ESD. For Catalyst 2900XL switches, the       issue is documented in Cisco bug ID       CSCdm13915 (registered customers only)         .

Failure of any of these diagnostic tests is normally fatal and usually       requires a Return Material Authorization (RMA) to resolve the problem. In order       to verify this, reset the switch with a console connection established and       capture the actual bootup diagnostic information. Then open a service request       with       Cisco       Technical Support.

Troubleshoot Fan Failures

Perform these actions if you suspect a fan failure:

  1. Check the LEDs. If all of the LEDs are off, check the power to the             switch. The fan can fail due to a power problem.

  2. Check the system LED. The system LED is amber if the system detects             a problem, and can indicate a fan problem if you cannot hear the fan in             operation. If you use a Catalyst 3524-PWR-XL, issue the show env             fan command to check the fan for failure.

Troubleshoot System Error Messages

System messages report any errors that the switch encounters. System       messages can appear in the command line interface (CLI) while you are connected       to the switch (through the console or Telnet). Syslogs are also recorded in the       system message log of the switch. In order to view the system message log,       issue the show logging command.

Refer to       System       Messages for syslog error message explanations and actions.

Troubleshoot High CPU

After you issue the show processes cpu command, the Catalyst 2900XL and Catalyst 3500XL switches report a high value       for CPU utilization when idle. With other Cisco devices, high CPU utilization       when idle is a cause for concern. However, such utilization is normal for       Catalyst 2900XL and 3500XL switches. Refer to       High       CPU Utilization on Catalyst 2900XL/3500XL Switches for more       information.

Troubleshoot high Memory utilization

High process Memory utilization

High process memory utilization occurs when you connect the Catalyst       switch to IP phones on a port through the dot1q trunks. The switch can be       configured with a number of VLANs. The switch sends spanning-tree BPDUs for all       VLANs to the IP phone connected through trunk to the switch. This causes the       memory utilization to increase on the switch.

When memory utilization increases, you can see an error message in the       tracebacks, which is similar to this:

Dec  5 15:51:31 MET: %SYS-2-MALLOCFAIL: Memory allocation of 568 bytes failed from 0x192C20, pool Processor, alignment 0
-Process= "STP Queue Handler", ipl= 6, pid= 56

As a workaround, configure only an allowed VLAN list on the ports       through the switchport trunk allowed vlan {add       vlan-list | all | except vlan-list | remove       vlan-list} command.

The allowed VLAN list must include only the VLANs that are necessary on       that port, which are usually the voice and data VLANs. Refer to Cisco bug ID       CSCdw22282 (registered customers only)          for more information.

Troubleshoot Expansion Slots in the Catalyst 2900XL

Expansion Slot Module Does Not Work

Perform these actions to troubleshoot possible expansion slot       problems:

  1. Issue the show version command to ensure that the switch recognizes the module ports. In order to ensure that the software you run supports the module, refer to the Release             Notes for the Catalyst 2900 Series XL and Catalyst 3500 Series XL Switches,             Cisco IOS Release 12.0(5)WC2.

  2. If you run the appropriate level of software, and the LED is still             amber, make sure that the module is seated properly and that the thumb screws             are tightened on the front pane of the module.

  3. If the module still does not appear to be operational, try the             module in another slot in the same switch. Alternatively, try the module in             another switch, if available.

ATM Module  Fails POST Tests

Refer to       Understanding       ATM Module POST Results for information on how to troubleshoot POST test       failure on the ATM module.

ATM Module Has Corrupt Module Software

Refer to       Recovering       from Corrupted Module Software.

Password Recovery for the ATM Module

Refer to       Recovering       from a Lost or Forgotten Password.

Troubleshoot  Interface Issues

Workstation cannot Log into the Network During Startup and cannot Obtain a DHCP Address

When you power up or reboot a client machine, if you observe one of       these symptoms, the problem can be due to an initial connectivity delay that       the switch introduces:

  • Microsoft networking client displays No Domain           Controllers Available.

  • Dynamic Host Configuration Protocol (DHCP) reports No           DHCP Servers Available.

  • A Novell Internetwork Packet Exchange (IPX) networking workstation           does not have the Novell Login Screen upon bootup.

  • An AppleTalk networking client displays Access to your           AppleTalk network has been interrupted. To re-establish your connection, open           and close the AppleTalk control panel. Sometimes, the chooser           application of the AppleTalk client either does not display a zone list, or           displays an incomplete zone list.

  • IBM network stations can display one of these messages:

    • NSB83619--Address resolution             failed

    • NSB83589--Failed to boot after 1             attempt

    • NSB70519--Failed to connect to a             server

See the Common Reasons and Solutions section for information on common reasons for this problem, and the solutions       to recover from the problem.

Common Reasons and Solutions

The reasons for these symptoms can be:

  • An interface delay caused by Spanning Tree Protocol           (STP)

  • EtherChannel, Trunking, or auto-negotiation           delay

Refer to       Using       Portfast and Other Commands to Fix Workstation Startup Connectivity       Delays for more information about these delays and their       solutions.

Contact       Cisco       Technical Support if you still face issues after you review and follow       the procedure in this document.

Troubleshoot NIC Compatibility Issues

When a server or client connection to the switch does not come up, look       for an autonegotiation issue. If you see errors on the port, check for a       Network Interface Card (NIC) compatibility issue, or an improper configuration       on the switch.

See the Common Reasons and Solutions section for more information.

Common Reasons and Solutions

The reasons for these symptoms can be:

  • A known NIC driver issue

  • A speed and duplex mismatch

  • Autonegotiation issues

  • Cabling problems

Refer toTroubleshooting       Cisco Catalyst Switches to NIC Compatibility Issues for more information       on how to troubleshoot these problems.

Troubleshoot Interface Errors

If you experience slow performance or intermittent connectivity, check       for interface errors. Issue the show controllers       ethernet-controller command in order to check for interface       errors for the port you troubleshoot. The Diagnostic       Commands section of this document explains this command.

Also issue the show interface command. The       Diagnostic Commands section explains this       command also. Refer to       Understanding       Data Link Errors for additional information on each counter and possible       causes.

This table lists some of the known issues with counters on the       Catalyst 2900XL and 3500XL series switches.

Symptom Description Fix or Workaround
Runts on a 802.1Q trunk port.A Catalyst 2900XL or 3500XL switch that receives a 64 or 66                     byte 802.1Q encapsulated frame on a trunk port counts the frame as a runt.                     However, the switch continues to forward the frame. This issue is commonly seen                     when you connect Cisco 7960 IP phones to the switch when you use auxiliary                     (voice) VLANs.                  This issue is cosmetic, and is due to an ASIC limitation. This                     issue does not cause any degradation in the performance of the switch. Refer to                     Cisco bug ID                     CSCds32999 (registered customers only)          for more information. Cisco IOS Software Release 12.0(5.4)WC1 or later
Cyclic Redundancy Check (CRC) on an Inter-Switch Link (ISL)                     trunk port.A Catalyst 3500XL or 2900XL Enterprise switch, with ISL                     trunking to the Fast Ethernet interface of a 7200-I/O-FE, 7500 PA-FE-TX, 3600                     or 2600, or KeepAlive Link State Packets (LSP) marked as CRC/Input errors on                     the switch. These errors do not cause any performance impact.                  Refer to Cisco bug ID                     CSCdr22809 (registered customers only)          for more                     information.The workaround is to disable KeepAlive on the router or use                     802.1Q trunking. No fix is available.
CRC on an ISL trunk port that connects to a Catalyst 5500/5000                     or 6500/6000 series switch.Trunking between a Catalyst 2900XL and a Catalyst 5500/5000 or                     6500/6000, with trunking negotiation through Dynamic Trunking Protocol (DTP)                     enabled on the Catalyst 5500/5000, causes CRC errors on the 2900XL due to the                     reception of non-ISL (DTP) packets. DTP or Dynamic Inter-Switch Link Protocol                     (DISL) sends out Protocol Data Units (PDUs) with both ISL and non-ISL                     encapsulated frames in order to speed up recovery from an out-of-sync situation                     for the hardware. An out-of-sync situation occurs when one side is trunk, and                     the other is not.                  Refer to Cisco bug ID                     CSCdm31600 (registered customers only)          for more information.                     Also, refer to Cisco bug ID                     CSCdr72128 (registered customers only)          for a variation of this                     issue. The workaround is to use the nonegotiate trunk mode on the                     Catalyst 5500/5000, so that DTP does not run . No fix is available.
Giants on ISL or 802.1Q trunk ports.When a Catalyst 2900XL switch receives a legal max-size                     Ethernet frame encapsulated or tagged for ISL or 802.1Q, and the packet is not                     forwarded to any other ports, the frame is counted as an oversize frame in the                     statistics counters.

Note: There are many valid reasons for a packet to be received and                       not forwarded to any other ports. For example, packets received in a port that                       STP blocks, are not forwarded.

Refer to Cisco bug ID                     CSCdm34557 (registered customers only)          for more information.
There is no workaround for this bug. This issue is cosmetic                     only and you can ignore this issue with switch performance problems. No fix is                     available.

The CDP-4-DUPLEX_MISMATCH Error Message on an ISL Trunk Port on a C3524-PWR-XL

If you receive a CDP-4-DUPLEX_MISMATCH error message on an ISL trunk port on a Catalyst 3524-PWR-XL, see the       Common Reasons and Solutions section for common       reasons for this problem, and the relevant solutions.

Common Reasons and Solutions

  • Make sure you have configured both sides with the same duplex.           Typically, trunk ports are configured as full duplex links. Make sure both           sides auto-negotiate correctly. If you hardcode on one side and set           auto-negotiation on the other side, a half-duplex configuration arises on the           auto-negotiate side of the link. Issue the show interface           interface id command to check the duplex           status.

  • You can encounter Cisco bug ID           CSCdx85015 (registered customers only)         . The workaround for this           bug is to issue the no power inline never interface           configuration command. The fix for the bug is available in Cisco IOS Software           Release 12.0(5)WC5a or later.

Support for Loopback Interfaces

The loopback interfaces are not supported in Cisco Catalyst       2900XL/3500XL Series Switches. Loopback interfaces are not supported in these       Cisco devices as they are purely Layer 2 switches and there is no need for any       lookback interfaces.

The interface loopback command is a       carry-over from the mainline Cisco IOS software releases and is not applicable       to these device platforms. When you enter the CLI commands that refer to a       loopback interface, it might trigger these messages to be displayed in the       log:

Assert failure in ../src-l2-les-common/stp_les_shim.c line 2524
Assert failure in ../src-l2-les-common/stp_les_shim.c line 2592
Assert failure in ../src-l2-les-common/stp_les_cli_cfg.c line 1261
Assert failure in ../src-l2-les-common/stp_les_cli_cfg.c line 1358
Assert failure in ../src-l2-les-common/stp_les_shim.c line 2558
Assert failure in ../src-l2-les-common/stp_les_shim.c line 2748

This issue is documented in Cisco bug ID       CSCsc43453 (registered customers only)         .

Troubleshoot  GBIC Issues

1000BASE-T GBIC is not Recognized or does not Work

GigaStack GBIC is not Recognized or does not Work Properly

GigaStack GBIC Link Flaps and Never Stabilizes

If your GigaStack GBIC link flaps and never stabilizes, refer to the       Link Flaps and Never Stabilizes section of       Catalyst       Switch GigaStack Configuration and Implications.

Troubleshoot GigaStack GBIC Based on LED Status

If your GigaStack GBIC Interface LED is not solid green (which       indicates normal function), refer to       Troubleshooting       GigaStack to troubleshoot on the basis of your LED status.

Troubleshoot GigaStack GBIC Loop Configuration

Software releases earlier than Cisco IOS Software Release 12.0(5)XU do       not support the GigaStack GBIC loop configuration. Earlier releases cause       excessive collision errors on the port and can cause the link to become       unstable. This instability decreases performance on the links. Communication       between the switches in the stack is adversely affected. Therefore, the loop       configuration is supported only if every device in the stack runs Cisco IOS       Software Release 12.0(5)XU or later.

Refer to the Cabling Configuration section of       Catalyst       Switch GigaStack Configuration and Implications.

Refer to       GBIC       Loop Configurations not Supported Before IOS Software Release 12.0(5)XU for a visual description of valid and invalid configurations.

The GigaStack GBIC module enables you to create a 1 Gbps stack       configuration of up to nine supported switches. The GigaStack GBIC supports one       full-duplex link (in a point-to-point configuration) or up to nine half-duplex       links (in a stack configuration) to other GigaStack-compatible Ethernet       devices. If you use the required Cisco proprietary signaling and cabling, the       GigaStack GBIC-to-GigaStack GBIC connection does not exceed three feet (or one       meter).

NO_LOOP_DETECT System Error Message with GigaStack GBIC

If you receive the NO_LOOP_DETECT, GIGASTACK, LOG_ALERT,       0, The link neighbor of link %d of GigaStack system message,       and want to understand or troubleshoot, refer to the Error Message:       NO_LOOP_DETECT section of       Catalyst       Switch GigaStack Configuration and Implications.

GIGASTACK-6-LOOP_DETECTED System Error Message with GigaStack GBIC

If you receive the %GIGASTACK-6-LOOP_DETECTED: Gigastack       GBIC in is selected as Master Loop Breaker system message,       refer to the Message: %GIGASTACK-6-LOOP_DETECTED section       of       Catalyst       Switch GigaStack Configuration and Implications.

Troubleshoot Console Connectivity Problems

This section explains strategies to troubleshoot console connectivity       problems.

Unreadable Characters on the Management Console

An incorrect baud rate setting on the management console typically       causes unreadable characters.

In order to resolve this problem, reset the emulation software on the       management console to 9600 baud (the default console baud rate of the switch).       If this action does not help, cycle through the various baud rate options on       the management console until you find one that works. The switch baud rate may       have been changed from the default.

No Connectivity Through the Console

Check this connectivity equipment.

Cisco Telnet Denial of Service

A specifically crafted TCP connection to a Telnet or reverse Telnet       port of a Cisco device that runs Internetwork Operating System (IOS)® can block       further access to the device through Telnet, reverse Telnet, Remote Shell       (RSH), Secure Shell (SSH), and in some cases Hypertext Transport Protocol       (HTTP). Data Link Switching (DLSw) and protocol translation connections can       also be affected. However, any Telnet, reverse Telnet, RSH, SSH, DLSw and       protocol translation sessions established before exploitation are not       affected.

All other device services operate normally. Services like packet       forwarding (excluding DLSw and protocol translation), routing protocols and all       other communication to and through the device are not affected.

Refer to Cisco bug ID       CSCef46191 (registered customers only)         . This bug tracks this problem. Also refer       to the related Security Advisory at       Cisco       Telnet Denial of Service Vulnerability.

Troubleshoot General Software Issues

Recover from Missing or Corrupted Software or Switch: Prompt

You need to recover the switch in these scenarios:

  • If your switch misses software

  • If your switch has a corrupt software image

  • If your switch is in Switch: prompt mode

  • If you receive the Error Loading Flash error message

Refer to       Recovery       From Corrupt or Missing Software Image on Cisco Catalyst 2900XL and 3500XL       Series Switches.

Troubleshoot Cisco Visual Switch Manager or Cluster Management Suite

If you have problems with your Cisco Visual Switch Manager or Cluster       Management Suite, refer to       Troubleshooting       Cisco Visual Switch Manager or Cluster Management Suite Access on the Catalyst       2900XL/3500XL/2950 Switch for procedures to troubleshoot (including Java       and browser requirements).

Hardware and Software Compatibility or Software Feature Support

Refer to these documents to identify the necessary software level to       support a certain hardware or software feature:

Recover Lost Password

Refer to       Password       Recovery Procedure for the Catalyst Layer 2 Fixed Configuration and 3550 Series       Switches to recover a lost password.

Diagnostic Commands

show interface

Enter the show interface command to check       for speed and duplex settings, error counters, input and output queues, input       and output rates, and to display the administrative and operational status of       the interface. Use the packets input and       packets output fields (from the output) to       determine whether traffic enters or leaves the interface.

switch#show interface  
  FastEthernet0/1 is down, line protocol is down 
  Hardware is Fast Ethernet, address is 00d0.5868.f181 (bia 00d0.5868.f181)
  MTU 1500 bytes, BW 0 Kbit, DLY 0 usec, 
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 3w6d, output hang never
  Last clearing of "show interface" counters 2w6d
  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
  0 packets input, 0 bytes
  Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
  0 watchdog, 0 multicast
  0 input packets with dribble condition detected
  0 packets output, 0 bytes, 0 underruns
  0 output errors, 0 collisions, 0 interface resets
  0 babbles, 0 late collision, 0 deferred
  0 lost carrier, 0 no carrier
  0 output buffer failures, 0 output buffers swapped out

Here are the counters that help you troubleshoot a problem on the       interface:

Input Errors

Input errors provide a count of any       errors that occurred during an attempt to receive packets from this port. The       counter includes both CRC and frame errors. However, this counter does not       include ignored packets. This is a list of input errors:

  • CRC Errors—These errors occur when the           received packets fail the CRC check.

  • Frame Errors—Frame errors occur when           the receiving frame is not complete.

  • Ignored Counter—This counter counts           the number of frames dropped on input due to resource exhaustion in the switch           fabric.

  • Overruns Counter—Overruns occur when           Inter-Frame Gaps (IFG) are too short. In this case, a new Ethernet frame           arrives before the previous one is completely stored in shared           memory.

Output Errors

Output errors provide a count of any       error that occurred while during an attempt to transmit packets from this port.

  • Collisions Counter—This counter shows           the number of times a collision occurred during an attempt to transmit a packet           from this port. This counter must be 0 for a port that operates in full-duplex           mode.

  • Interface Resets Counter— This counter           counts the number of times the port resets, generally due to link up or link           down transitions.

  • Underruns Counter—Underruns occur when           packets are not retrieved quickly enough from shared memory to be           transmitted.

Babbles and Late Collisions

Babble errors occur due to the       transmission of frames in excess of 1518 bytes in size. A late       collision occurs outside of the collision window and occurs due       to a duplex mismatch or a wire that exceeds the distance limitations (100       meters for 10/100 ports). The deferred counter       tabulates the number of times the port waits to transmit due to traffic on the       wire.

Lost Carrier and No Carrier

A carrier is an electrical signal that Ethernet devices use to detect       whether another transmitting station uses the wire currently. The       lost carrier counter increases when the carrier       sense loss occurs when the hardware transmits a frame onto the wire and does       not see its own carrier wave on the Ethernet. Absence of the carrier signal       increments the no carrier counter.

show controllers ethernet-controller

The show controllers ethernet-controller command provides in-depth information about a specific interface as shown       here:

Switch# show controllers ethernet-controller fa0/4  
   Transmit                     Receive
   26869777 Bytes               402753236 Bytes
   460 Unicast frames           1 Unicast frames
   45408 Multicast frames       198165 Multicast frames
   12207 Broadcast frames       0 Broadcast frames
   Discarded frames             0 No bandwidth frames
   Too old frames               0 No buffers frames
   Deferred frames              0 No dest, unicast
   0 1 collision frames         0 No dest, multicast
   0 2 collision frames         0 No dest, broadcast
   0 3 collision frames         1 Alignment errors
   0 4 collision frames         0 FCS errors
   0 5 collision frames         0 Collision fragments
   0 6 collision frames
   0 7 collision frames         0 Undersize frames
   0 8 collision frames         198166 Minimum size frames
   0 9 collision frames         65 to 127 byte frames
   0 10 collision frames        28 to 255 byte frames
   0 11 collision frames        256 to 511 byte frames
   0 12 collision frames        512 to 1023 byte frames
   0 13 collision frames        1024 to 1518 byte frames
   0 14 collision frames        0 Oversize frames
   0 15 collision frames
   0 16 Excessive collisions    1102 Late collisions

Most of the fields in the output are self-explanatory. This table       explains platform-specific counters:

Fields Explanation Action
Discarded frames The total number of frames whose transmission attempt is                     abandoned due to insufficient resources (such as underrun). This total includes                     frames of all destination types.Reduce the traffic load destined to that interface if you see a                     rise in the number of packets in this field.
Too old frames Number of frames that took longer than two seconds to travel                     through the switch, and the switch discarded the frames. This situation only                     occurs under extreme, high stress conditions.Reduce the switch load if you see a rise in the number of                     packets in this field.
Deferred frames The total number of frames whose first transmission attempt had                     to be delayed due to traffic on the network media. This total includes only                     those frames that are subsequently transmitted without error and without a                     collision.Reduce the switch load if you see a rise in the number of                     packets in this field.
No bandwidth frames and                     No buffers frames The number of times a port received a packet from the network.                     However, the switch does not have the resources to receive the packet. This                     situation occurs only under stress conditions, but can occur with bursts of                     traffic on several ports. So, a small number in the No bandwidth                     frames field is not a cause for concern. Ensure that this value                     is far less than 1 percent of the frames received.Reduce the traffic load on the particular                     interface.
No dest, unicast Number of times that a unicast packet is received. The port                     determines that the packet must not be forwarded to any other                     ports.See below.
No dest,                     multicast Number of times that a multicast packet is received. The port                     determines that the multicast packet must not be forwarded to any other                     ports.See below.
No dest,                     broadcast Number of times that a broadcast packet is received. The port                     determines that the broadcast packet must not be forwarded to any other                     ports.See below.

This is a brief description of example scenarios to receive an       increase in the No dest counter.

  • If STP blocks a port, most packets are not forwarded. This results in           No dest packets.

  • If a port just acquired a link, there is a very brief (less than one           second) period where incoming packets are not forwarded.

  • If a port is an access port, and the port is connected to an ISL           trunk port, the No dest counter shows a very           large value. All the incoming ISL packets are not forwarded. This is an invalid           configuration.

  • If a lone port is in a VLAN, and no other ports on the switch belong           to that VLAN, the port drops incoming packets.

  • Port A receives a packet with destination MAC address X. The switch           has already learned that the MAC address X resides on port A. This situation           arises if a hub is connected to port A. One workstation connected to the hub           transmits packets to another workstation connected to the hub. This scenario is           also possible if a switch is connected to port A, and the other switch           temporarily floods packets to all ports while it learns the addresses.

  • If a static address is set up on another port in the same VLAN, and           no static address is set up for the receiving port, the packet is dropped. For           example, if a static address is set up to specify that if the destination MAC           address X is received on port f0/2, the packet must be forwarded to port f0/3.           If a packet with the destination MAC address X is received on any port other           than f0/2, but in the same VLAN as f0/2, the packet is           dropped.

  • If the port is a secure port, packets with disallowed source MAC           addresses are not forwarded.

show env fan

The show env fan command is applicable only       to the Catalyst 3524PWR-XL switches. This command helps to identify whether the       system fan is faulty. If so, replace the switch.

Switch# show env fanFAN 1 is OK
FAN 2 is OK
FAN 3 is OK
FAN 4 is OK
FAN 5 is OK

show logging

The show logging command helps to check the       logged system messages. Make sure logging is enabled if you do not see any       messages in the output of this command, in the console, or in the syslog       server. Enable timestamps with the service       timestamps global configuration command.

3500XL>show loggingSyslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 102 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 102 messages logged
File logging: disabled
Trap logging: level informational, 108 message lines logged

Log Buffer (4096 bytes):
by console
00:09:55: %LINK-3-UPDOWN: Interface FastEthernet0/48, changed state to down
00:09:56: %LINEPROTO-5-UPDOWN: 
   Line protocol on Interface FastEthernet0/48, changed state to down
00:13:30: %SYS-5-CONFIG_I: Configured from console by console
00:50:27: %CMP-CLUSTER_MEMBER_2-5-ADD: 
   The Device is added to the cluster (Cluster Name: 
   CH-3500-8, CMDR IP Address
1w3d: %SYS-CLUSTER_MEMBER_2-5-CONFIG_I: Configured from console by console

show platform port-asic stats drop

The show       platform port-asic stats drop command provides the real       drops and indicates towards-traffic microbursts which cause the egress buffer       to exhaust.

Switch#sh platform port-asic stats drop gig1/0/1
  Interface Gi1/0/1 TxQueue Drop Statistics
    Queue 0
      Weight 0 Frames 0
      Weight 1 Frames 0
      Weight 2 Frames 0
    Queue 1
      Weight 0 Frames 0
      Weight 1 Frames 43472041
      Weight 2 Frames 1
    Queue 2
      Weight 0 Frames 0
      Weight 1 Frames 0
      Weight 2 Frames 0
    Queue 3
      Weight 0 Frames 0
      Weight 1 Frames 0
      Weight 2 Frames 3631857
    Queue 4
      Weight 0 Frames 0
      Weight 1 Frames 0
      Weight 2 Frames 0
    Queue 5
      Weight 0 Frames 0
      Weight 1 Frames 0
      Weight 2 Frames 0

  not sure why this was added , these products have been dead  since 2006 .