Showing results for 
Search instead for 
Did you mean: 

WS-C2960S-24TS-L and CRC errors

Level 1
Level 1


I am observing CRC/FCS errors (together with Recv-err) on 2960S on ports connected to ALCOMA radios (1gbps ethernet link). The strange thing is I have the same radios connected to another cisco switches (2960G, 3560G, 2960) and there is no such problem. We tried to install a 3560G between the radio and 2960S and the problem disappeared.

Currently we have 5 2960S with the same problem.

It looks like the ports on 2960S are somewhat different. Now I don't know who is the bad boy. Cisco or ALCOMA? Any hints what to do now?

5 Replies 5

Kimberly Adams
Level 3
Level 3


What does the speed and duplex configurations look like between the 2960S and the ALCOMA?  It is running autonegotion or speed locked? 

Thanks and Cheers!


Please remember to rate helpful posts.

Thanks and Cheers! Kimberly Please remember to rate helpful posts.

Leo Laohoo
Hall of Fame
Hall of Fame

Please post the following commands:

1.  sh version;

2.  sh interface ;

3.  sh controll e ;

4.  sh controll u

Level 1
Level 1


Thanks for your fast answers.

It looks like we found the primary problem source. ALCOMA allows us to force its interface to Master or Slave mode. The default value is Auto and for same cause ALCOMA and 2960S fails to negotiate who will be master and who will be slave. If we switch ALCOMA's interface to Slave CRC error are gone. It is not the settings I prefer but at least we know why the packets are damaged.

To answer Kimberly's and leolaohoo's questions:

- we use autonegotiation (speed and duplex) and the llinks truly run 1000/full

- utilization of the controler is low (most of the radios allow about 160mbps of throughput)

- the ethernet-controller output looks like the one bellow. I think it could correspond to the fact that the transceiver and receiver aren't synchronised (both in Master mode probably). And could explain why one heavily loaded link has less error rate than the other with lower load (some switch/radio interface clocks are closer then another ones)

Now I would like to know if we can get some info about gigabit ethernet negotiation process - I would like to know whether the interface is Master or Slave and if there is possibility to debug the negotiation itself it would be fine.


Dalibor Toman


sh controllers ethernet-controller gi1/0/24

     Transmit GigabitEthernet1/0/24           Receive

   1823273899 Bytes                        378538317 Bytes

    872966155 Unicast frames              1269921000 Unicast frames

        11370 Multicast frames                167662 Multicast frames

       633994 Broadcast frames               6910380 Broadcast frames

            0 Too old frames              4055798667 Unicast bytes

            0 Deferred frames               12354573 Multicast bytes

            0 MTU exceeded frames          571945106 Broadcast bytes

            0 1 collision frames                   0 Alignment errors

            0 2 collision frames               13979 FCS errors

            0 3 collision frames                  13 Oversize frames

            0 4 collision frames                   0 Undersize frames

            0 5 collision frames                   7 Collision fragments

            0 6 collision frames

            0 7 collision frames            81507355 Minimum size frames

            0 8 collision frames           175156632 65 to 127 byte frames

            0 9 collision frames            71168518 128 to 255 byte frames

            0 10 collision frames           33322138 256 to 511 byte frames

            0 11 collision frames           31026282 512 to 1023 byte frames

            0 12 collision frames          884834996 1024 to 1518 byte frames

            0 13 collision frames                  0 Overrun frames

            0 14 collision frames                  0 Pause frames

            0 15 collision frames

            0 Excessive collisions              9102 Symbol error frames

            0 Late collisions                   6212 Invalid frames, too large

            0 VLAN discard frames                  0 Valid frames, too large

            0 Excess defer frames                 10 Invalid frames, too small

    469401611 64 byte frames                       0 Valid frames, too small

    258591422 127 byte frames

     48832732 255 byte frames                      0 Too old frames

     15849024 511 byte frames                      0 Valid oversize frames

     17489351 1023 byte frames                     0 System FCS error frames

     63447379 1518 byte frames                     0 RxPortFifoFull drop frame

            0 Too large frames

            0 Good (1 coll) frames

            0 Good (>1 coll) frames

Level 1
Level 1


I have found the problem about 2960s.Sometimes the port the port will become orange that I met a few times.When the problem occured ,I did: shutdown and no shutdown the port ,so It recovered.But don't just so,you could open the Recv-err ,so It can automatically recover.

So I didn't know why the port become orange ,but I have met twice.But this method can solve this problem.

I hope this can help you.


I think our problem is completely different from yours.

Probably you could find problem source/description in the 'show log'. When the port gets to orange it could be a problem with trunk/access autonegotiation (set the mode desired manually), problem with spanning tree, detection of some unexpected state (BPDUs received), port blocked by storm control or so.

In some cases you can try to configure 'errdisable recovery cause xy' to allow the port to receovery from blocked state...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card