Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!hsdndev!spdcc!dirtydog.ima.isc.com!ism.isc.com!b1!ico!dougm
From: dougm@ico.isc.com (Doug McCallum)
Newsgroups: comp.sys.novell
Subject: Re: IPX corruption possible across routers
Message-ID: <1991Jun10.193718.5008@ico.isc.com>
Date: 10 Jun 91 19:37:18 GMT
References: <1991Jun3.142905.29531@aio.jsc.nasa.gov> <1991Jun3.212342.4603@npd.Novell.COM> <1056@rsp.UUCP>
Reply-To: dougm@ico.ISC.COM (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 26

In article <1056@rsp.UUCP> tom@rsp.UUCP (Thomas Ruf) writes:
>timm@Sed.Novell.COM (Tim Myers) writes:
>
>>You've been talking to those IP-on-the-backbone-or-bust bigots again,
>>haven't you?
>>Software CRCs are redundant since Ethernet interface cards do it for you in
>>hardware.  IPX was designed to NOT waste any time computing redundant CRCs.
>
>Ha Ha Ha ! Ethernet CRC is just that: a link level checksum. It does NOT
>cover:
>	RAM errors in routers
>	Software problems in routers
>	Link Errors in OTHER medias between Etherent segments
>I'd rather have my CPU spent some cycles checking end-to-end checksums
>as in tcp/ip than blindly trust all those fancy boxes moving bits over
>the ocean. 

Things can be worse than just routers and other intermediate
devices on the LAN.  I've seen some LAN cards which appear as
memory to the host develop problems with their RAM.  The Ethernet
CRC gets generated after that so appears as a correct packet on
the local LAN.  You don't notice until some file has become
corrupted.

Of course, if Novell did use checksums it would be very difficult
to tell a Novell 802.3 packet from any 802.3/802.2 packets.