From: ssw@bronze.ucs.indiana.edu (steven wallace)
Subject: Re: Weird Ethernet Behavior
Organization: Indiana University
Date: Sat, 3 Oct 1992 13:10:20 GMT

In <Oct.2.23.09.45.1992.3178@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:

>I'm sort of surprised that no one from Cisco has stepped in to
>authoritatively stop this rumor.  I guess a bug is possible, but as
>far as I can tell, Cisco Ethernet support checks the Ethernet CRC for
>all protocol types.  It also checks the HDLC CRC for serial lines that
>use HDLC.  There was a bug in one version of MCI microcode that caused
>it not to check the HDLC CRC.  We did in fact see errors due to this
>(in Novell, I believe), and they stopped when the microcode was fixed.
>I do not believe we've seen undetected errors otherwise, and our
>network is complex enough (and uses NFS enough) that I think we would
>have.  One reasonable indication is that we do see CRC errors counted
>on Ethernet interfaces that are handling only IP traffic.

Cisco, are you listening???

I'm familiar with the old serial line problem, but we still see what
appears to be IP packets with bad CRCs forwarded.  They are counted as
CRC errors, but still forwarded.  Other protocols with CRC errors are
also counted are not forwarded.  When I said IP still worked I was
referring to ping (ICMP echo request).  Ping is not reliable, so
retransmissions were not masking the problem.

>The original evidence was that someone had a repeater that was
>destroying the end of packets, including the CRC, and IP still worked.
>I suspect IP worked because the TCP or NFS was retransmitting the
>packets after they were discarded because of CRC failure.  I assume
>some packets were OK.  If not, then you'd expect that at least TCP
>would fail, since the TCP checksum would cause the packet to be
>discarded even if the Ethernet checksum would not.  If all packets are
>discarded, the user is going to complain that he can't connect.

Again, Ping was used for testing so retransmissions weren't masking the
problem.  All the IP protocols in this situation worked fine because
only the CRC portion of the ethernet frame was trashed.  We've seen
worse problems where more of the ethernet frame was trashed causing NFS
problems similar to the ones the guy form KSU was describing.  If the IP
head checksum is OK, the router will forward the packet (regardless of
the ethernet CRC).  The IP header check doesn't include the payload
portion of the packet and most NFS implementations by default have UDP
checksuming turned off for performance reasons.   This wasn't happening
to all packets, but enough to cause problem with NFS and some slow down
in TCP.


>I can believe that some microcode rev of some Ethernet interface might
>have had a problem of not reporting CRC failures.  But not that there
>is a general problem with all Cisco equipment, nor an intentional
>design choice to ignore CRC (as one posting implied).

Only cisco can ansere this, but we've got over 50 ciscos and all supported
media but token ring and I've seen this several times.
-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Acting Associate Director     |  wallaces@iubacs          (bitnet)
Network Systems UCS           |  (812) 855 - 0960         (voice)