Internal Rx Errors: on gig uplinks (CSS11150)

[cdeeds]

Has anyone ever ran across what causes "Internal Rx Errors:"? I've noticed that this counter is increasing quite rapidly, after clearing the interface stats first of course. This is occuring on my uplink interfaces (e13 and e14) which are the gig interfaces on the CSS. I've found an explanation of the errors in the CSS documentation:

"Internal RX Errors

The number of frames for which reception on the interface failed due to an internal MAC sublayer receive error."

But I'm still a little unclear about how to go about how to rid the CSS of these errors as well as what is and isn't acceptable as a threshold for these errors.

Thanks in advance,

cdeeds

[owillins]

The Rx errors mean not getting packets back correctly from service.

I found the following bug corresponding to the issue of Internal Rx errors on gig ports. CSCdv48405. You could view the details using the Bug Toolkit. This occurs because the CSS's gig ports only work in full duplex mode.

[cdeeds]

Hmm...very interesting. The bug details does not explain if the errors are something to be concerned about or what can be done to fix the problem. I'll keep looking though. Thank you for the information!

[Gilles Dufour · Accepted solution]

the internal notes gives more info :

------------------

RxErros is a catchall for sync loss, fifo full,

delimiter sequence, gmac drop and symbol errors.

---------------------

This is not really a bug - that's why there is no solution to it.

This RxError just indicates that you have link issues.

You can try to swap cables, or the interface on the other side.

Or do nothing if you don't see packet drops.

Gilles.

[cdeeds]

I think that I'm just going to keep monitoring the interfaces for now since I don't have any hard evidence, i.e. dropped packets etc., that would lead me to believe that this is causing a performance degredation. Thank you for the information, it was very helpful in getting to the bottom of this mystery!

[dcayer]

We have encountered the same errors on our CSS11150's.

Configuration #1:

Servers <-GigE-> Cat4006 <-GigE-> CSS11150 <-FastE-> Firewall.

In configuration #1, the "Internal RX Errors" for the GigE ports on the CSS were indicate drops due to contention for slower egress ports (ingress is GigEthernet, egress is FastEthernet). We have decided to use configuration #2 (we no longer use the CSS GigEthernet ports). We are letting the Cat4006 switch take care of the GigE-to-FastE buffering, but this does not appear to have improved the situation.

Configuration #2:

Servers <-GigE-> Cat4006 <-FastE-> CSS11150 <-FastE-> Firewall.

With configuration #2, the CSS is no longer logging the "Internal RX Errors" for the GigE ports. Instead, the Cat4006 is now logging "txQueueNotAvailable" errors for the FastEthernet port connected to the CSS.

Basically, GigE flow control doesn't seem to work between our servers and the Cat4006 and CSS switch ports. Luckily, all of the sensitive/critical applications hosted on our servers run on TCP (which takes care of retransmission)!

Hope this makes sense...

Dan

[Gilles Dufour]

there are many networks where the GigE link works fine with a CSS.

I would say most of them works.

However it is sometimes required to play a little bit with the parameters.

Try to use different pause frames (symetric - asymetric - no pause).

There must be a combination that works fine.

Gilles.