Alignment Errors and Frame Check Errors

[Dennis D Hagen]

We're seeing constant reporting of the following errors in our Opcom log, but users are not experiencing any problems. Any suggestions as to the cause and possible solution?

%%%%%%%%%%% OPCOM 17-DEC-2007 06:49:17.14 %%%%%%%%%%%
Message from user SYSTEM on ...
Event: Frame Check Error from: Node LOCAL:... CSMA-CD Station CSMACD-0,
at: 2007-12-17-06:49:17.140-08:00Iinf
eventUid 2FB981BC-AC6C-11DC-9EF3-0000F806C945
entityUid BB3B1393-ABE2-11DC-80B3-AA0004000104
streamUid BFCBD947-ABE2-11DC-80CF-AA0004000104

%%%%%%%%%%% OPCOM 17-DEC-2007 06:49:17.17 %%%%%%%%%%%
Message from user SYSTEM on ...
Event: Alignment Error from: Node LOCAL:.... CSMA-CD Station CSMACD-0,
at: 2007-12-17-06:49:17.173-08:00Iinf
eventUid 2FBE6C81-AC6C-11DC-9EF3-0000F806C945
entityUid BB3B1393-ABE2-11DC-80B3-AA0004000104
streamUid BFCBD947-ABE2-11DC-80CF-AA0004000104

[Volker Halle · Accepted solution]

Dennis,

when did this start ? Did anything get changed at the LAN adapter level of this node (LAN adapter, cable, switch port) ? Is the LAN device setting the same on the VMS system and the switch ?

$ MC LANCP SHOW DEV/CHAR ?

Volker.

[Jim_McKinney]

Most common; this could be a mismatch of speed and/or mode. Check the speed and duplex settings on your NIC and on the adjacent switch port (nowadays I presume you're using a switch) and make sure that they agree. If either is autonegotiating then they both should be.

[Heinz W Genhart]

Hi Denis

I guess that you have a hardware problem or the mode settings of the ethernet card are not correct.

Try replacing the Networkcables and / or use another port on the switch.

Check the mode Settings in console mode (e*_mode). Depending on the switch in use this should be set FAST_FD or Autonegotiate.

Regards

Geni

[Richard Brodie_1]

$ MC LANCP SHOW DEV/CHAR

is useful, like Volker said. I would usually look at the output of

$ MC LANCP SHOW DEV/COUNT also, to get some quantative error data.

[John Gillings]

Even more useful for diagnosing duplex mismatches is:

$ MCR LANCP SHOW DEV/INTERNAL

This will tell you how an adapter is set on the console, and the results of any autonegotiation. For example:

Device Internal Counters EIA0:
...
--- Driver Messages ---
6-NOV-2007 10:30:21.08 Link state change: UP
6-NOV-2007 10:30:18.04 Full Duplex 100BaseTX connection selected
6-NOV-2007 10:30:18.04 FastFD mode set by console
...

Device Internal Counters EWA0:
...
--- Driver Messages ---
6-NOV-2007 10:30:19.32 Link up: 1000 mbit, full duplex, flow control (txrx)
6-NOV-2007 10:30:16.53 Device type is BCM5703C (UTP) Rev A0 (11000000)
6-NOV-2007 10:30:16.52 DEGXA-TB located in 64-bit, 33-mhz PCI slot
6-NOV-2007 10:30:16.52 Jumbo frames enabled per system parameter LAN_FLAGS bit 6
6-NOV-2007 10:30:16.52 Auto-negotiation mode set by console (EGA0_MODE)

Oh, and I'd rephrase what Jim said from:

"If either is autonegotiating then they both should be."

to:

"If either is autonegotiating then they both MUST be (no discussion, no arguments, no exceptions, *MUST* be)"

[Richard Stockdale]

Usually if there is a duplex mode mismatch, you would also see opcom messages and error log entries for 'potential duplex mode mismatch' and the error count on the device would be going up.

But if there are sporadic alignment and CRC errors you won't see a duplex mode mismatch message. These also show up in the LANCP SHOW DEV/INTERNAL_COUNTERS or just SHOW DEV/MESSAGES.

So assuming that there really isn't a duplex mode mismatch, then these are probably real errors and the earlier suggestions for changing the switch port or cable are good for starters.

It might help to see the bad packets - you can look at them with LAN driver tracing, MC LANCP SET DEV/TRACE=(SIZE=1003,MASK=(%X7000,0),STOP=(%X2000,0)) EWA and then MC LANCP SHOW DEV/TRACE EWA after collecting an error.

Depending what the switch does with bad packets - it can forward them if it is doing cut-through switching or if it is doing store and forward, it would likely discard them instead. If it is forwarding them, then it would be very helpful to see who is actually generating the bad packets.

Tracing the bad packets only works on devices that return status on receive packets. In V8.4 and remedial streams (soon) the Broadcom and Intel gigabit drivers have a device specific function that can be enabled via LANCP to allow you to enable reception of bad packets so you can then trace them.

- Dick

[Richard Stockdale]

I forgot to mention, I assumed that the device in question is a Tulip (DE500 or 21143 LOM chip) as that is the only device that will log DECnet events like this because the drivers for all of the other (modern) devices disable reception of bad frames.

- Dick

[Dennis D Hagen]

Thanks for the assistance. It was a mismatching of autonegotiating.