03-28-2013 07:59 AM - edited 03-07-2019 12:31 PM
Hi,
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?
03-28-2013 02:27 PM
Hello,
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!
Kimberly
Please remember to rate helpful posts.
03-28-2013 07:39 PM
Please post the following commands:
1. sh version;
2. sh interface
3. sh controll e
4. sh controll u
03-29-2013 12:35 AM
Hi,
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.
Regards
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
03-29-2013 07:06 AM
Hello
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.
03-29-2013 08:13 AM
Hi,
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...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide