From: tsiang@cisco.com (David Tsiang)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 7 Oct 1992 23:27:37 GMT
Organization: cisco Systems, Incorporated
Distribution: world
NNTP-Posting-Host: tsiang-ss2.cisco.com


-- 

What interface cards are you using?  I know that for the MEC (an AGS+ card) there is 
a small window where the interface chip will not automatically flush bad CRC'd 
packets like it should.  This only seems to occur on 'bad' networks and seems
to occur most often when fiber repeaters are involved.  The good news is that
although the interface chip does not flush the packet, it does mark the CRC bad
status bit.  With the latest and greatest MEC microcode (Ver 2.4), we no longer 
rely on the interface chip to flush a packet and we do an explicit check of
the CRC status bit.

So if you have an MEC and are seeing this problem, I would upgrade the microcode
to Ver 2.4.



David Tsiang
High End Systems Development
cisco Systems - HW engineering
Menlo Park, California
email:  tsiang@cisco.com

In article <1ahhtcINNma4@moe.ksu.ksu.edu>, bav@hobbes.ksu.ksu.edu (Brick Verser) writes:
|> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
|> >In <1aee3aINNfgk@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
|> >
|> >>In article <BvF94p.9CA@usenet.ucs.indiana.edu> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
|> >>>A cisco will look at the IP header checksum, not the ethernet checksum,
|> >>>when deciding whether to forward the packet or not.
|> >
|> >>Are you sure about this?  On most systems, the ethernet CRC is checked by
|> >>the interface, not the host software.  In particular, if the CRC is
|> >...
|> >
|> >Yep, I pretty sure.  I've seen very direct evidence of this.  Maybe
|> >cisco will chime in here and explain.  Of course the router doesn't
|> >...
|> >We've had broken repeaters that destroyed the tail of ethernet
|> >frames (thus the checksum), but not the headers.  The symptoms are
|> >IP will works just fine, but Novell or Appletalk packets don't pass
|> >through the router and are counted as input error on the interface
|> >stats.
|> 
|> This is, basically, what we were seeing.  Sending UDP packets across the
|> bad fiber transceiver through the AGS we would see coming out the other 
|> end things like this:
|> 
|>  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
|>  nopqrstuvwxyz{|}~ !"#$%&'()*+,-./012345678)*******
|> 
|>  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
|>  nopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=.**
|> 
|>  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
|>  nopqrstuvwxyz{|}~ !"#$%&'()*+,-./012345678UUUUUUUU
|> 
|> The tail end of about one every 10000 packets was getting stomped.  It didn't
|> matter for IP since it's checksummed, but UDP checksumming is turned off
|> by default in SunOS under the assumption that the Ethernet CRC check will
|> catch problems.  It felt like collisions were simply not being caught
|> somehow and instead the packets were being accepted in their mangled form
|> by the router.  If the Cisco is not verifying CRCs on Ethernet packets
|> then it seems like there's a major potential for NFS catastrophies lurking.
|> 
|> --Brick
Newsgroups: comp.dcom.sys.cisco